Combining a ResolverTemplateAttributeDefinition with a SAML2StringNameID element

[Karla Borecky]

Thank you, Scott.  I'll play with this on my test/dev system.

Karla




On Thu, Sep 5, 2013 at 4:28 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 9/5/13 3:25 PM, "Karla Borecky" <kborecky at smith.edu> wrote:
>
> >The problem is, some of the people who use this service don't get email
> >accounts from us--only LDAP accounts. (It used to be authenticated with
> >LDAP.)  I am loathe to put their non-Smith email addresses in the "mail"
> >attribute of these accounts, since those addresses are outside our domain.
>
> You certainly *can* in terms of how the attribute is defined, but you can
> easily end up with problems for other reasons.
>
> >Since this service is only using the email address as a unique
> >identifier, I thought of using eppn as the nameID -- but I understand now
> >that scoped attributes don't exist in their final @SCOPE format within
> >the attribute-resolver.
>
> That's up to you, it depends what you define and what the data is to begin
> with.
>
> >1. The sourceAttributeID for the nameID definition would be the ID listed
> >in the attribute definition template, yes? (bold and red in example
> >below):
>
> There are dozens of ways to do anything in the resolver.
>
> You don't have to create a separate attribute definition to encode
> something as a NameID that already exists, but you can of course.
>
> >...and the attribute definition template would have to precede the nameID
> >section...? (or no?)
>
> I don't understand what you mean by "nameID section". The order in the
> resolver never matters, it's a directed graph. It will build the tree when
> it loads to determine what has to run first.
>
> >3. Can I leave my nameid-format at this:
> >
> >
> >
> >nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
> >
> >since the end product will be in the general format of an email address?
>
> You should use that format if the result *is* an email address. Otherwise
> no.
>
> > or should I use
> >
> >nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>
> You should never use that value, and it should never have been defined
> (and would not have been had I won an argument).
>
> >(which is what our Gmail definition uses)? I would tend to think
> >"unspecified" would be the one to use, since I'm basically making this
> >attribute up.
>
> No, if you're making it up, then you should (or the SP should) define a
> URI for it, the same as with any custom attribute you might create. There
> is no way to have an "unnamed" Attribute in SAML, and the mistake was in
> having a way to do something like that for NameID formats.
>
> >4. The SP has "emailAddress" as the nameid format in their metadata as
> >well, so I assume whatever I use (emailAddress or unspecified), they
> >would use, yes?
>
> The metadata won't matter unless you're relying on it as part of the
> process for driving the NameID selection process, but that is one way to
> do it that you can use to avoid having to touch relying-party.xml.
>
> >5. Would they put my nameID attribute as the FriendlyName of the
> >attribute in this section:
> >
> ><md:RequestedAttribute FriendlyName="mail"
> >Name="urn:oid:0.9.2342.19200300.100.1.3"
> >NameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress"/>
>
> There is no standard for encoding that, but conventionally using the
> NameID Format as the Name of the RequestedAttribute is a reasonable
> choice. I would doubt you have anything looking at that metadata anyway.
>
> FriendlyName has absolutely no relevance to any code.
>
> >Or...instead of having two separate chunks, could I create some
> >monstrously complicated AttributeDefinition block that would do all of
> >this in one fell swoop?
>
> Yes, but I wouldn't call "add an additional AttributeEncoder" monstrous,
> it's one line.
>
> That assumes you have an actual attribute definition that itelf contains
> the exact data for every user. If the point is that you don't, then yes,
> you should create one.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130906/802a70ee/attachment.html