Combining a ResolverTemplateAttributeDefinition with a SAML2StringNameID element

[Cantor, Scott]

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