RequestMap Query applicationId

[Tom Haenen]

>For the record, you aren't intended to use different attribute mapping rules, that's why you can map any attributes you get into any headers you want, including many to one or one to many.

You assume that all email addresses provided are the same, although I am not sure this is always the case. 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. 

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. 


>I can't think of any reason offhand Query wouldn't work, but Path most certainly does, so you are incorrect.

>Path based overrides are a bad idea, but they are covered in detail in the ApplicationModel page. They are very complicated for people without experience with the software. Don't use them. And you don't need any overrides at all based on what you've described as a use case, at least minimally.

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. Which would explain why <Path> does not work if the attribute mapping is based on the application id for /Shibboleth.sso/SAML2/POST. Does this explanation make any sense? If so, then path based overrides will not work for us.

--Tom