[EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

[O'Quinn, Dennis]

Hi Peter, see my previous reply for some of this...  RE: the IdP/SP support philosophy, in our case we are a closed corporate environment and the only 'entities' involved are, of course, our on departments and security controls much of this which is probably not like the more public environment you are used to.  That doesn't give the right to not do it right of course, and I will be discussing this with them.

Regarding the 'environment' concept, this (SAML?) is very oriented towards an educational environment from whence it came...  However, I see that it is (or has) moved out of that realm into a more 'generic' environment.  At the risk of opening a can of worms, I wonder if anyone has given thought to updating the documentation/references/nomenclature to something more generic.  I know that 'some' of my confusion/distraction was based on all the 'edu....' example and references because I was not aware of the historical background relating to SAML/Shibboleth....  Just a thought...

D

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Peter Schober
Sent: Tuesday, June 12, 2018 4:23 AM
To: users at shibboleth.net
Subject: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

* O'Quinn, Dennis <DENNIS_OQUINN at homedepot.com> [2018-06-12 00:14]:
> Thanks, but, not sure how to apply that guidance.  This is what the 
> IdP is sending me.  Are you saying I can override that someway and 
> 'change' it to eduPersonPrincipalName?

You're mapping the attribute from 'name="eppn"' to 'id="eppn"', literally in the attribute-map.xml.
(The only way to make this more obvious -- other than the documentation explaining that this is what happens -- would be calling the parameters 'from' instead of 'name' and 'to' instead of 'id'.)

It's the latter (the 'id' you've chosen in your attribute-map.xml) that triggers the SP's built in checks for the eduPersonPrincipalName attribute, and that's what's reventing you from using it.

> BTW, Much of the documentation I am reading out there seems to imply 
> that the configuration is being done by 'one' entity with access to 
> "both" IdP and SP configurations and logs simultaneously.

No. But either way: I pointed out everything that was wrong with that attribute as sent by the IDP (which was everything can can possibly be wrong).
While you may not have the power to change it you're still free to convince the IDP that what it does is wrong and not interoperable.
Assuming you're not the only SP in the world it's likely that the next SP will then not have to go through your experience, once the IDP fixes this.

-peter
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=MtgQEAMQGqekjTjiAhkudQ&r=mn6DeBt1nj8Oqx06pdIK0_n5EfK6FeVHgdjBNpchyro&m=5xm_dFrF4KEIAh-09quTvG3f-zWjjNU7rCsFr1nb2Tw&s=9v-1-dRAjSbriXn8XhNqXKWkBFfndpfnkv8Btq1JuIo&e=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net