<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Thanks everyone. Andy your example worked like a charm.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Best always,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Kathy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 3:57 PM, Andrew Morgan <span dir="ltr"><<a href="mailto:morgan@orst.edu" target="_blank">morgan@orst.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 31 Aug 2015, Nate Klingenstein wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Kathy,<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></span>
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.<br>
<br>
The SAML AuthnRequest you get from Okta says:<br>
<br>
<saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" /><br>
<br>
but that DOESN'T WORK. The metadata you download from Adobe says:<br>
<br>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br>
<br>
The identifier we decided to use with Adobe is EPPN, so I encoded it as persistent.<br>
<br>
In Okta's SAML Response to Adobe, they took my persistent EPPN and encoded it as unspecified. Crazy stuff...<br>
<br>
<br>
<br>
I'm sorry, but I neglected to include one additional thing. In relying-party.xml, I have:<br>
<br>
<!-- Added for Adobe --><br>
<rp:RelyingParty id="<a href="https://www.okta.com/saml2/service-provider/spi1fhbo6hBnuyO5O0x7" rel="noreferrer" target="_blank">https://www.okta.com/saml2/service-provider/spi1fhbo6hBnuyO5O0x7</a>" provider="<a href="https://login.oregonstate.edu/idp/shibboleth" rel="noreferrer" target="_blank">https://login.oregonstate.edu/idp/shibboleth</a>" defaultSigningCredentialRef="IdPCredential"><br>
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never"/><br>
</rp:RelyingParty><br>
<br>
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".<br>
<br>
Andy<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><font face="verdana, sans-serif" size="2" style="font-size:small">Infrastructure & Ops<br></font><span style="font-family:verdana,sans-serif;font-size:small">Clemson University<br></span><span style="font-family:verdana,sans-serif;font-size:small">CCIT, 340 Computer Court<br></span><span style="font-family:verdana,sans-serif;font-size:small">Anderson, SC 29625<br></span><a href="mailto:kewrig@clemson.edu" style="color:rgb(17,85,204);font-size:small;font-family:verdana,sans-serif" target="_blank">kewrig@clemson.edu</a><br><span style="font-family:verdana,sans-serif;font-size:small">(864) 656-8133</span></p></div></div></div></div>
</div>