Adding custom attributes based on entityID

[Andy Bennett]

Hi,

> A percentage of the clients we integrate with prefer to use one of their
> own custom attributes for user identification as opposed to using the
> EPPN.  In order to abstract the burden of treating different attribute
> values as the user ID in our application, we decided to define every
> custom attribute with the same id and give preference to its usage over
> the EPPN; see example below.

We've had similar woe, even though the number of attributes we deal with
is less. I posted about our experience in the thread "skipping duplicate
Attribute mapping (same name and nameFormat)" on 2014/09/04 to this list.

Our SP maps several URNs to persistent-id and one URN to targeted-id and
then, in our app, have a per IDP field which says whether to use the
"persistent-id" or "targeted-id" CGI variable. Our app can tell which
IDP is involved using the "Shib-Identity-Provider" CGI variable.

We've found it to be sub-optimal to map more than one URN to a given CGI
variable because some IDPs send several of the attributes which get
mapped to, for example, a multi-valued "persistent-id" CGI variable. The
problem comes when these values are different. Naturally, this is a
misconfiguration on the part of the IDP. However, we cannot fix that and
at least one IDP we've dealt with can't fix it either. They tried, but
discovered that some SPs use one value and some use the others and the
only service which notices the discrepancy is ours. They couldn't
disable the release of either one and didn't have enough infrastructure
in place to arrange for a different release policy just for us.

...so even tho' it's "wrong", we had to take it.


So my recommendation is to map each URN attribute to a separate CGI
variable attribute *AND* have app infrastructure in place to select a
particular CGI variable based on the IDP it's coming from. This will
allow you maximum flexibility and enable you to know who's sending what.

The idea is to try to guarantee a single valued CGI variable for each
SAML attribute.

In our case we can't retrospectively tell how, say, a 2 valued
"persistent-id" CGI variable has been decoded from the three possible
input URNs to "persistent-id". Because the SP won't decode more than one
identical attribute (same name and nameFormat) to different CGI
variables we can't migrate away from our arrangement because, in the
multivalued-but-different cases, it's not possible for us to choose a
guaranteed working key for each IDP.




Regards,
@ndy

-- 
andyjpb at knodium.com
http://www.knodium.com/