IdP 2.4 and Okta/Adobe.com SSO
morgan at orst.edu
Mon Aug 31 15:57:40 EDT 2015
On Mon, 31 Aug 2015, Nate Klingenstein wrote:
> 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
> 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="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"/>
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