Reverse attribute mapping..

[Cantor, Scott]

On 8/2/13 7:15 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>The design of the reverse mapper was done with an eye to the
>"urn:mace:shibboleth:2.0:attribute-map"  schema which the SP implements,
>but
>following our current plan of not introducing any more custom parsers in
>V3
>we decided to initially configure this via Spring only.

Emphasis on "initially", I would say this is an experiment. I'm
comfortable working to achieve native spring configuration of web flows
and their beans, and anything that is mostly a "single touch" sort of
file, but I'm not convinced we'll get there with the attribute machinery
or that we really want to.

Particularly if we can embed native Spring syntax to configure complex
beans and features inside our custom schemas, like in the LDAP connector
case.

>I have just worked through a small example based on the some of the
>attribute definitions in the V2 attribute-resolver.xml, with a couple of
>changes to try to explore some of the oddness that the config has to deal
>with - in particular the ability to go encode one IdP attribute as two
>SAML
>attributes and for the same SAML attribute to be encoded by two IdP
>attributes.

I think your example there is off. If you have two AttributeDefinitions
encoding to the same SAML, you still have to give them a separate id.
Having two id="eduPersonAssurance" doesn't work, I don't think. Am I wrong?

>I checked this in to svn under
>idp-attribute-filter-spring:src/test/resources/net/shibboleth/attribute/ma
>pp
>er/attributesmapper.xml

What's the difference between the two files there?

>2) The current implementation uses the identification of the
>SAMLAttributeMapper to provide the identity of the IdP attribute.  I find
>that this is incredibly inelegant in the Spring configuration and unless
>someone says so I'm going to change that such that the id is just an id
>(so
>for instance one could use the SAML friendlyName) and put all the
>attribute
>IDs into the alias.

You mean where it says 	p:id="eduPersonAssurance" ?

Yes, I wouldn't call the property aliases, I'd just call it attributeIDs
or some such.

>3) Otherwise it hangs together reasonably sensibly.

Can a bean property (valueMapper) be shorthanded? Or were you just
comparing syntaxes there?

Also, can a property like that be defaulted? Can we default to
StringAttributeValueMapper?


>4) I am still intending spending some time to see whether it is possible
>to
>create a system to map from the attribute filtering engine to this
>configuration.

You mean resolver engine?

>If people with an interest in this area could look that example file and
>check for correctness as well as make any other comments, I'd be very
>grateful.

I asssumed p:sAMLName should just be p:SAMLName.

Is there a shorthand for specifying lists?

-- Scott