<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008G7VWKSA3Okta Classic EngineOkta Integration NetworkAnswered2024-04-30T09:18:25.000Z2015-09-26T05:11:57.000Z2018-08-12T04:17:00.000Z

JeffM.43402 (Customer) asked a question.

Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:20 AM
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!
  • 5 answers
  • 2.9K views

  • j5v7c (j5v7c)

    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:

    0EMF0000000XbKn

     

    Thanks,

     

    Douglas Coburn

    Sales Engineer

    Okta
    Expand Post
    Selected as Best

  • j5v7c (j5v7c)

    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:

    0EMF0000000XbKn

     

    Thanks,

     

    Douglas Coburn

    Sales Engineer

    Okta
    Expand Post
    Selected as Best

  • JeffM.43402 (Customer)

    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!
    Expand Post

  • svcV.75126 (Customer)

    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
    Expand Post

  • JeffM.43402 (Customer)

    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
    Expand Post

  • svcV.75126 (Customer)

    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
    Expand Post
This question is closed.
Loading
Can okta return a nameid that is persistent, but anonymous?