IdP 2.4 and Okta/ SSO

Andrew Morgan morgan at
Mon Aug 31 15:57:40 EDT 2015

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:


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

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="" provider="" defaultSigningCredentialRef="IdPCredential">
         <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never"/>

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".


More information about the users mailing list