​IAM / ​Projects / Shibboleth / Service Candidates / Origami

Origami is a service for risk management: ​http://origamirisk.com/

UA OIT Project Manager is Toni Abbey. A target completion date for integration with UA Shibboleth login is 10 February 2014.

As of 17 January 2014, basic information is still missing, referred to in the following email:

From: David Bantz <dabantz@…>
Subject: UA SAML assertion and NameID
Date: Wednesday, 4 December 2013 at 12:11:23 AKST
To: Jonathan Nichols <jnichols@…>

Dear Jon,

As we discussed, my first task toward integration of Origami’s service and UA Identity Provider for SSO seems for me to better understand your desire for NameID.

Part of my confusion is that NameID can be defined as an attribute much like any other (analogous to a phone number or address of the principal except that phone/address may be shared or reassigned and a NameID should not be); but NameID is also used in the authentication portion of the SAML assertion - as the “subject” of the assertion.

I understood or mis-understood you to want NameID in the subject to be a persistent identifier of the principal. That should be possible, but it’s different from our practice with other services.

Our practice is that the subject uses NameID from any identifier available. Note this portion of the logs detailing an interaction with our IdP:

14:54:47.036 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:509] - Filtering out potential name identifier attributes which can not be encoded by edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.036 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528] - Removing attribute eduPersonAffiliation, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.036 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528] - Removing attribute eduPersonScopedAffiliation, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.036 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528] - Removing attribute surname, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.036 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:523] - Retaining attribute transientId which may be encoded to via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.037 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528] - Removing attribute eduPersonPrincipalName, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.037 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528] - Removing attribute givenName, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.037 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528] - Removing attribute onemail, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.037 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528] - Removing attribute displayname, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.037 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:672] - Selecting attribute to be encoded as a name identifier by encoder of type edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:54:47.037 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:699] - Selecting the first attribute that can be encoded in to a name identifier
14:54:47.037 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:483] - Name identifier for relying party 'https://oeadev1.cac.washington.edu/shibboleth' will be built from attribute 'transientId'
14:54:47.038 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:864] - Using attribute 'transientId' supporting NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' to create the NameID for relying party 'https://oeadev1.cac.washington.edu/shibboleth'
14:54:47.038 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:729] - Attempting to encrypt NameID to relying party 'https://oeadev1.cac.washington.edu/shibboleth'

In this case, the subject nameID was built from a transientID - exactly the opposite of what you want for a persistent identifier of the principal. My concern about relying on the nameID in the subject is this process of selection by the IdP may make it hard to guarantee that the subject will be the identifier you want.

Our practice is that a service that needs a persistent identifier or key will use one of the attributes we can release - such as the uakPersonID (which is scoped to alaska.edu) or the un-scoped version bannerId. For example, for me, these are (in the SAML assertion):

<saml2:Attribute FriendlyName="uakPersonID" Name="https://iam.alaska.edu/trac/wiki/IamUaArp#uakPersonID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance” xsi:type="xs:string">30459959@…</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute FriendlyName="bannerID" Name="https://iam.alaska.edu/trac/wiki/IamUaArp#bannerID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance” xsi:type="xs:string">30459959</saml2:AttributeValue>

</saml2:Attribute>

I’ve described our practice not to insist that’s how we do it, but to help you help me understand what you need so I can determine what I need to do to meet the needs of your service.

So to summarize, here are the options I see:

(1) Rely on uakPersonID (or bannerID) attributes we are set up to release. uakPersonID does have the characteristics of a “Name Identifier” (​https://wiki.shibboleth.net/confluence/display/SHIB2/NameIDAttributes) .
(2) Encode the uakPersonID or bannerID as an attribute of type SAML23NameID with a named-format rather than encoded as uri as we currently do.
(3) Encode these existing attributes with a different name if that’s needed.
(4) Ensure the uakPersonID identifier encrypted in the subject of the SAML assertion; that is the only option that will require significant work on my part.

I hope this provides you enough information to help us determine what needs to be done. Please let me know.

Thank you,

David Bantz U Alaska Identity & Access Mangement