Origami – IAM / Shibboleth

Context Navigation

Version 4 (modified by dabantz@…, 11 years ago) (diff)
--

IAM / Projects / Shibboleth / Service Candidates / Origami

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

(1) Origami was unable to provide metadata description of their service. So UA is required to manufacture metadata for the service.

<EntityDescriptor entityID="https://demo.origamirisk.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
   <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

       <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>

       <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
           Location="https://demo.origamirisk.com/Origami/SSO/SamlLogin?providerAccount=UofAK" />
   </SPSSODescriptor>
</EntityDescriptor>

<EntityDescriptor entityID="https://live.origamirisk.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
   <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

       <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>

       <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
           Location="https://live.origamirisk.com/Origami/SSO/SamlLogin?providerAccount=UofAK" />
   </SPSSODescriptor>
</EntityDescriptor>

(2) Attribute release policy; to meet customer requirements to respond differently to employees vs students, and active/current vs. inactive members, Origami agreed to consume and use indicators of affiliation (eduPersonAffiliation) and indicators of being currently-enrolled student (use creditHoursCurrent) and currently active employee with a job or assignment (use assignmentCount). Heres' the release policy, applied to both the test ("demo") and production ("live") services.

<AttributeFilterPolicy id="releaseToOrigami">
   <PolicyRequirementRule xsi:type="basic:OR">
                <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://demo.origamirisk.com" />
                <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://live.origamirisk.com" />
        </PolicyRequirementRule>
    <AttributeRule attributeID="assignmentCount">
        <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
    <AttributeRule attributeID="creditHoursCurrent">
        <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
    <AttributeRule attributeID="bannerID">
        <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
    <AttributeRule attributeID="eduPersonAffiliation">
        <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
    <AttributeRule attributeID="displayname">
         <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
    <AttributeRule attributeID="email">
        <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
</AttributeFilterPolicy>

(3) Because they are not providing a certificate to be used in the transaction, it is necessary to disable encryption of SAML assertions to the service with a special relying-party configuration [prior to including this relying-party configuration, the IdP error'd out attempting to respond to authentication request]. In relying-party.xml

<!-- Origami provides no metadata or cert, so disable encryption  -->
   <RelyingParty id="https://demo.origamirisk.com"
       provider="urn:mace:incommon:alaska.edu"
       defaultSigningCredentialRef="IdPCredential"
       defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
      <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
   </RelyingParty>
   <RelyingParty id="https://live.origamirisk.com"
       provider="urn:mace:incommon:alaska.edu"
       defaultSigningCredentialRef="IdPCredential"
       defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
      <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
   </RelyingParty>

(4) For at least the initial testing, we used the following URL: https://demo.origamirisk.com/origami/account/login?account=UofAK

At the vendor end, the authentication request sent is a POST with the following XML payload:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest ID="_4241073183472CBDEA1BB2FCE42AB2E2" Version="2.0" 
   IssueInstant="2014-02-05T00:55:15Z" 
   Destination="https://idp.alaska.edu/idp/profile/SAML2/POST/SSO" 
   ForceAuthn="false" 
   IsPassive="false" 
   ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
   AssertionConsumerServiceURL="https://demo.origamirisk.com/Origami/SSO/SamlLogin?
      providerAccount=UofAK" 
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo.origamirisk.com
</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" />
</samlp:AuthnRequest>

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

2014-01-22: Discussion with Jon Nichols:

Jon states there will be two modes of logging in to Origami, SSO (for "ordinary" UA users) and "direct" (for Risk Management folk). Jon was unaware of need for exchange of PKI certificates to establish trust, and does not believe Origami has such metadata. email'd back with reference to Shibb documentation on SP metadata and a copy of UA IdP metadata, restating need for SP metadata.

On Wed, 22 Jan 2014, at 14:06 , Jon Nichols <jnichols@…> wrote:

David,
 
Thanks for the call today.  Just to confirm.
 
1.        You will be providing an attribute  of <bannerID> which will contain the 30 million number
2.        Your assertion will provide an attribute that will identify the user as either an employee, student or both.
 
You also had a couple of additional questions which I was not able to address at the time in reference to additional metadata from us.  I have copied in Linus Concepcion who built our SSO interface and will be handling the coding changes necessary for this project.  Please reach out to him with the additional questions you have.
 
Regards
 
Jon
 
Jonathan Nichols
Origami Risk LLC
Director of Client Services
847-786-2069
jnichols@origamirisk.com

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

From: David Bantz <dabantz@Alaska.edu>[[BR]]
Subject: UA SAML assertion and NameID[[BR]]
Date: Wednesday, 4 December 2013 at 12:11:23 AKST[[BR]]
To: Jonathan Nichols <jnichols@origamirisk.com>

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@alaska.edu</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) .[[BR]]
(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.[[BR]]
(3) Encode these existing attributes with a different name if that’s needed.  [[BR]]
(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.[[BR]]

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

Download in other formats:

Plain Text

Context Navigation

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

Download in other formats:

IAM / Projects / Shibboleth / Service Candidates / Origami