IdP 2.4 and Okta/Adobe.com SSO

[Andrew Morgan]

On Mon, 31 Aug 2015, Nate Klingenstein wrote:

> Kathy,
>
> I’ll bet that Okta is acting as an IdP proxy here: an SP to us and an 
> IdP to Adobe.  From what I understand, Okta typically thinks of 
> themselves as your IdP, provisioned from your user stores 
> asynchronously.
>
> I’d see if that’s the case before I spent too much time chasing this — 
> or, here, debugging something that might not be part of the transaction 
> at all.

Yes, that is exactly what is happening.  If you run an authentication 
through SAML Tracer, you'll see a SAML request from Okta, a SAML response 
from your IDP to Okta, and a SAML response from Okta to Adobe.

The SAML AuthnRequest you get from Okta says:

   <saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

but that DOESN'T WORK.  The metadata you download from Adobe says:

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

The identifier we decided to use with Adobe is EPPN, so I encoded it as 
persistent.

In Okta's SAML Response to Adobe, they took my persistent EPPN and 
encoded it as unspecified.  Crazy stuff...



I'm sorry, but I neglected to include one additional thing.  In 
relying-party.xml, I have:

     <!-- Added for Adobe -->
     <rp:RelyingParty id="https://www.okta.com/saml2/service-provider/spi1fhbo6hBnuyO5O0x7" provider="https://login.oregonstate.edu/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">
         <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never"/>
     </rp:RelyingParty>

Basically, don't encrypt anything.  They don't include an encryption key 
in their metadata, and Shib will give an error for this even though 
encryptAssertions defaults to "conditional".

 	Andy