RequestMap Query applicationId

Cantor, Scott cantor.2 at
Wed May 14 10:03:58 EDT 2014

On 5/14/14, 6:39 AM, "Tom Haenen" <tom.haenen at> wrote:
>You assume that all email addresses provided are the same, although I am
>not sure this is always the case.

I don't assume that, I assume the opposite.

> For example the attributes
>urn:mace:dir:attribute-def:eduPersonPrincipalName and
>urn:mace:dir:attribute-def:mail are not guaranteed to contain the same
>data. One of our customers might ask us to use eduPersonPrincipalName,
>while another does not use this attribute for their email addresses.

That's exactly what the mapping capabilities are designed to address.

>Another reason to keep the attribute maps separate per IdP is that the
>combined attribute map will be a spaghetti mapping that is harder to

The alternative is the rest of the configuration becomes much harder to
maintain. You end up with extra SAML endpoints to publish for every

>I did some more testing, my using an invalid applicationId I get the
>error messages as expected, showing that the application id does work as
>expected for <Path> and <Query>. When I use a correct applicationId, I do
>NOT get the <AttributeExtractor> specified in the <ApplicationOverride>.
>I suspect it does not work because the authentication comes back
>/Shibboleth.sso/SAML2/POST instead of the path defined in <Path>

That means you didn't supply an overridden handlerURL and Sessions element.

There's a section on path-based overrides and the implications of doing

-- Scott

More information about the users mailing list