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