IdP 2.4 and Okta/Adobe.com SSO

[Kathy E. Wright]

Thanks everyone.  Andy your example worked like a charm.

Best always,
Kathy

On Mon, Aug 31, 2015 at 3:57 PM, Andrew Morgan <morgan at orst.edu> wrote:

> 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 

Infrastructure & Ops
Clemson University​
CCIT, 340 Computer Court
Anderson, SC 29625
kewrig at clemson.edu
(864) 656-8133
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150831/c677a875/attachment.html>