RequestMap Query applicationId

[Cantor, Scott]

On 5/14/14, 6:39 AM, "Tom Haenen" <tom.haenen at reqtest.com> 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
>maintain.

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

>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>
>/Login.aspx.

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

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOve
rride

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

-- Scott