Okta SP NameIDPolicy Format working with Shibboleth IdP 3.x Skip to main content
https://support.okta.com/help/answers?id=906f0000000i0lvia0&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:
Ryan Tapp (Admin)Ryan Tapp (Admin) 

Okta SP NameIDPolicy Format working with Shibboleth IdP 3.x

Our current Okta implementation uses our own Shib IdP to faciliate a seamless SSO experience for our users when working with our Shib-enabled applications.  The Okta SP (https://www.okta.com/saml2/service-provider/XXXXXXXXXX) in the AuthnRequest is specifying a NameIDPolicy Format of 'transient' and I would like this to be either 'unspecified' or 'emailAddress' but I don't know if this is something I can change on my end (there is no option in Security -> Identity Provider that I can find and I haven't had much luck trying to use the Transform Username to get away from NameID).  The issue is that Shib IdP 3.x works a bit differently in respects to transient NameID generation, and although I can make Shib IdP 3.x work like v2.x (and everything works as it does now when I do that), this is a deprecated feature of IdP 3.x and I'd like to see if I can use the 3.x default with Okta.  It appears I need to have the Okta SP either specifically request 'unspecified' or 'emailAddress' or perhaps not request any format and let me specify that from the Shib IdP (all just a guess).  Has anyone experienced this or have any suggestions before I open a call with support?  Thanks.
Best Answer chosen by Niki (Okta, Inc.) 
Wils DawsonWils Dawson (Okta, Inc.)
Hi Ryan,

We do support changing the NameIDPolicy via API at the moment.

http://developer.okta.com/docs/api/resources/idps.html#saml-20-settings-object

It's not exposed in our UI yet, but the use case is supported.

Hopefully that helps,
Wils

All Answers

Wils DawsonWils Dawson (Okta, Inc.)
Hi Ryan,

We do support changing the NameIDPolicy via API at the moment.

http://developer.okta.com/docs/api/resources/idps.html#saml-20-settings-object

It's not exposed in our UI yet, but the use case is supported.

Hopefully that helps,
Wils
This was selected as the best answer
Ryan Tapp (Admin)Ryan Tapp (Admin)
Thanks Wils, that does help.  It's curious though, that the default is listed as unspecified, but ours is set to transient.  It makes me think ours was specifically set at implementation.  I'll ask support about it.  Thanks again. 
Ryan Tapp (Admin)Ryan Tapp (Admin)
So I solved my issue.  For anyone that might be interested, here's what I was able to do.  I actually did use the Transform Username function in Identity Provider, but I think this only worked because of the implementation work originally done by Okta.  I might have been barking up the wrong tree on the NameIDPolicy Format.

Our Shibboleth IdP is releasing the three basic attributes that Okta wants: FirstName, LastName and email.  In looking at what other attributes the Okta IdP understands, ldapMail was defined but not being used.  So I had our Shib IdP release ldapMail but encoded the identifier I wanted to use as that attribute.  Then by using the Transform Username option, I was able to select ldapMail to use for Username.  The value I want to use as Username is basically 'eppn' so it looks like an email address to Okta but is unique and immutable (unlike the 'email' attribute).

When I try to define a second IdP in Okta, I can't get ldapMail as an option, so I'm guessing it was defined by the implementer and we probably need a license to define custom attributes at this point, but in any case I was able to re-use the same IdP settings as already configured.  Needless to say, our implementation of marrying two IdP's together is not standard and probably anyone else attempting to do this would have a completely unique situation and configuration as well, but maybe this post will help.