Can okta return a nameid that is persistent, but anonymous? Skip to main content
https://support.okta.com/help/answers?id=906f0000000blumiay&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Jeff MinardJeff Minard 

Can okta return a nameid that is persistent, but anonymous?

I would like to use okta to authenticate my users, however I do not wish the application I am creating (which receives the SAML response) to have any real user info delivered to it. The nameid typically includes some form of email (which are real names) or, well, real name. 

Is there some form of nameid that is both persistent and anonymous?

Thanks!
Best Answer chosen by Jeff Minard
Douglas CoburnDouglas Coburn (Okta, Inc.)
Hi Jeff,

When setting up a SAML App configuration in Okta you are able to specify the Application Username Format. The default tends to be to use the e-mail or Okta Login user id. If this is not desired you can actually populate this with a custom expression for what will be used as the user id, providing it matches the target application, and have a custom entry. For example in my Salesforce configuration my username is firstname@domain.com and so is my e-mail. My salesforce user id though, for an existing user, was first initial, lastname @ domain.com (dcoburn@domain.com). So I used a custom expression in order to create this:

${f:toLowerCase(f:substring(user.firstName, 0, 1))}${f:toLowerCase(user.lastName)}@${f:substringAfter(user.email, "@")}

Now I could use any attribute I wanted to instead of firstname or LastName. If the user is AD Mastered I could create a custom attribute in the Okta profile and have the AD attribute mapped to that which could be the customer User ID. That way I could do:

${user.customAdAttribute)

Screenshot of my Configuration:
Screenshot of using custom expression


Thanks,

Douglas Coburn
Sales Engineer
Okta

All Answers

Douglas CoburnDouglas Coburn (Okta, Inc.)
Hi Jeff,

When setting up a SAML App configuration in Okta you are able to specify the Application Username Format. The default tends to be to use the e-mail or Okta Login user id. If this is not desired you can actually populate this with a custom expression for what will be used as the user id, providing it matches the target application, and have a custom entry. For example in my Salesforce configuration my username is firstname@domain.com and so is my e-mail. My salesforce user id though, for an existing user, was first initial, lastname @ domain.com (dcoburn@domain.com). So I used a custom expression in order to create this:

${f:toLowerCase(f:substring(user.firstName, 0, 1))}${f:toLowerCase(user.lastName)}@${f:substringAfter(user.email, "@")}

Now I could use any attribute I wanted to instead of firstname or LastName. If the user is AD Mastered I could create a custom attribute in the Okta profile and have the AD attribute mapped to that which could be the customer User ID. That way I could do:

${user.customAdAttribute)

Screenshot of my Configuration:
Screenshot of using custom expression


Thanks,

Douglas Coburn
Sales Engineer
Okta
This was selected as the best answer
Jeff MinardJeff Minard
Douglas,

Thanks for the reply.

I've seen the cusom options, but simply reformatting the name doesn't really get me what I'd want.

That said, taking custom attributes from AD which are non-pii would make sense. However, my dev instance isn't backed by AD so I don't think I have that option. I will check with my IT admins to see what they could cook up though.

Ideally, it'd be quite useful is the okta expression language had a String.md5() or sha1(). For now, I'll edit the profile, include "employeNumber" and use that.

Thanks!
api-workday api-workdayapi-workday api-workday
Hi Jeff,

For a number of reasons I am of the opinion that immutability and opacity should be the basis for all usernames.

While I have NOT had the luxury of a greenfield environment where i could experience this in totality i have been able to transform username standards in a few places to meet this criteria.

The gap I see associated with having a oneway hashing algo available in the OEL would be the inability to ensure the inputs remained consistent.  In my environ both username (until all of my legacy usernames have left or been renamed to the new standard) and employeenumber are subject to change. Perhaps for your purposes you could rely on an attribute to remain constant and the hashing algo would provide the desired opacity.

If you could use the Okta user id in the application you are building would that work for you?

-Matt
Jeff MinardJeff Minard
Hey Matt,
 
For a number of reasons I am of the opinion that immutability and opacity should be the basis for all usernames

On immutability, I totally agree. On opacity, from the SP perspective I may be an edge case. Namely, I plan to integrate this application to my company's internal AD, but the SP will be hosted external to the corporate network. In order to prevent PII from leaking (all our emails are first.last@company.com) I specifically do not want user names present to the SP to be opaque.

As for immutability, I don't think I have that particular hang up. I suspect that employee id from the AD I plan on targetting is fairly static; as this is an internal SP integration, I needn't worry about integrations with everyone/everywhere.

All that said, I would think you'd run into this problem regardless of whether you use a hash or any of the simpler transforms currently supported -- if the source of your transform changes so to shall the output. Some transforms will be less susceptible to this, but I doubt any come out unscathed at scale.

Finally, yes, I also suspect that using the okta user id would also work for my purpose. I had, in fact, originally looked around for just that, but didn't turn anything up.

Regards,

- Jeff
api-workday api-workdayapi-workday api-workday
Hi Jeff,

There is a new function in the OEL that a little birdy told me about that exposes a mechanism for retrieving the okta id of a user.

getInternalProperty is the name of the function and the usage in the UD mapping would be user.getInternalProperty("id") -> app.userName. The result of this configuration is that the nameid of the SAML assertion will be the okta userid.

The configuration needs to be done in the profile mappings area similar to the mapping we discussed in the other thread https://support.okta.com/help/answers?id=906F0000000blURIAY