SP: making a saml attribute out of a header

[Marc Boorshtein]

Just to circle back, I uncommented the LDAP attributes in
attribute-map.xml and changed my attribute to
urn:mace:dir:attribute-def:cn and it worked.  Thanks for pointing me
in the right direction.

As for listing all the attributes, it wouldn't be useful for
production but would be useful for testing.

Thanks
Marc

On Fri, Sep 28, 2012 at 12:35 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/28/12 6:39 AM, "Peter Schober" <peter.schober at univie.ac.at> wrote:
>>
>>What's provided as FriendlyName? Though that might potentially allow
>>circumventing all kinds of policies (send OID for phone number and
>>claim for it to be ePPN?), so I'm not actually suggesting it.
>
> I hadn't thought of it. That's SAML 2 only of course.
>
> But I don't know what the threat model would be. It essentially lets the
> IdP assign the local name of the attribute which is then then the basis of
> policy. I'm not sure what the implications would be. Maybe nothing.
>
>>Taking the attribute Name from the assertion might be another
>>option.
>
> I think that would be bad because all the punctuation in a URI would be
> turned into underscores, which leads to a lot of questionable names that
> might overlap. But I suppose it probably has a similar threat model to
> using FriendlyName.
>
>> But then people will start hardcoding rules based on such
>>names and lose the abstraction that the SP provides for them (SAML1 vs
>>SAML2 names, etc.)
>
> Among other things, yes. Using wire names is definitely a bad idea.
> FriendlyName is more akin to using LDAP short names, which is hardly a new
> idea, but with LDAP, I believe the short name / OID mappings are local to
> the client. So essentially exactly what the SP does now.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net