help with NameIDs

[Andrew Morgan]

On Thu, 28 Jul 2016, Mark K. Miller wrote:

>
> Hello again,
>
> So, I've heard that NameIDs are dealt with in a completely new way with IdP 
> v3; I've even heard that it's 'waaaaay easier now.'  Sadly, the easier IdP v3 
> way has me completely flummoxed.  Everything I've tried has either had no 
> effect whatsoever, or it's broken it completely and no NameID even gets 
> created.  :-(
>
> In v2 I did one of three things.  I either sent the default NameID, or I had 
> a NameID of "unspecified" format that was sent, or I had a NameID of 
> "persistent" format that was sent.  Both of the non-default NameIDs had their 
> value assigned by using the value of the eduPersonPrincipalName attribute. 
> So, they were created in attribute-resolver.xml, and then one of them was 
> always part of the release policy in attribute-filter.xml.
>
> Now, for v3, I see in the wiki that there could be at least four files I have 
> to use to get this done.  There's still the attribute-resolver where the ePPN 
> gets created.  Then, there's the saml-nameid.xml file where the NameID 
> generators are enabled and the NameIds are generated.
>
> I'll say now it starts to get a little fuzzy; in reality, though, it started 
> getting fuzzy somewhere in saml-nameid.xml.  Since I mentioned a NameID with 
> persistent format, I've seen reference to setting the appropriate properties 
> in the saml-nameid.properties file.  But, what properties would that be if I 
> just wanted to assign an ePPN value to a NameID?
>
> And, finally (?), since I mentioned a NameID with an unspecified format I 
> think I've seen where that now requires something in the relying-party.xml 
> file to trigger a profile configured with an appropriate 
> nameIDFormatPrecedence property.
>
> So, I think I've found references in the wiki for each specific part of 
> handling NameIDs in v3, but I'm clearly missing something about how all these 
> pieces 'fit together'.  Can anyone provide a pointer for an example that 
> actually creates one (or two) NameIDs, and shows what's needed in each of the 
> files above to get that done?  And, what about this stuff that needs added to 
> the relying-party.xml file?  Can this new, version 3 bean to configure a 
> profile to trigger the nameIDFormatPrecedence property just be added 
> somewhere into an existing, legacy relying-party.xml file like you'd have 
> after doing an upgrade?
>
> Any guidance greatly appreciated!
>
> Max

Max,

One very important thing to keep in mind - the v3 IDP generates NameIDs 
based on format(s) in the SAML request or the SP's metadata.  If the SAML 
request from the SP says it wants a particular NameID format, the IDP will 
try to do that.  If the SAML request doesn't specify which format (or it 
unhelpfully requests "unspecified"), the IDP will use the format from the 
SP's metadata.

Note: there is no format "unspecified".  If the SAML request or metadata 
says "unspecified", you can return whatever you want (whatever your 
configuration says).


I think I have a configuration that is similar to what you're describing.

For almost all SPs, we are generating and releasing a transient NameID. 
This is the NameID that the IDP makes up on the fly and base64-encodes. 
It looks like:

AAlzZWNyZXQyMjmLONxSdwmYukIDNBGRWxvL9aBnrlF+2FWzpKqcbTpycga4cbZDz7zCGS6eCgMkvWfw9Z/TVmOnfgYnatrmFf+JnTIO2HBxrxIkhEi2AlHHAiugJsUMDKbJeXOskPpCgYJJD0rbBNgjProsfO8X


A few SPs use NameID instead of just using attributes.

WebEx wants a NameID with format "persistent".  We put this in 
saml-nameid.xml:

         <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
             p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
             p:attributeSourceIds="#{ {'webex-principal'} }">
             <property name="activationCondition">
                 <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="https://oregonstate-staff.webex.com" />
             </property>
         </bean>

This bean says if https://oregonstate-staff.webex.com requests a 
"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameID, generate it 
from the 'webex-principal' attribute (which maps internally to EPPN in 
attribute-resolver.xml).

Google asks for the "email-address" format.  We have a special attribute 
for the google principal.  For everyone else that requests 
"email-address", we release EPPN.  Here is that configuration:

         <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
             p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
             p:attributeSourceIds="#{ {'eduPersonPrincipalName'} }">
             <property name="activationCondition">
                 <bean parent="shibboleth.Conditions.NOT">
                     <constructor-arg>
                         <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="google.com/a/oregonstate.edu" />
                     </constructor-arg>
                 </bean>
             </property>
         </bean>
         <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
             p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
             p:attributeSourceIds="#{ {'google-principal'} }">
             <property name="activationCondition">
                 <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="google.com/a/oregonstate.edu" />
             </property>
         </bean>


We're not doing anything with what the IDP has traditionally called a 
persistent identifier internally (the database-backed generated value).


Don't forget to release the attributes that you are basing the NameID on 
(in attribute-filter.xml)!


I hope this helps.  Let me know if you have any questions.

Thanks,
 	Andy