<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 4/26/17 5:23 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:F663D6C2-78C4-465E-BB3E-3FABC508174B@osu.edu">
<pre wrap="">
</pre>
<blockquote type="cite"><br>
<pre wrap="">
Well, actually it doesn't. There is no AttributeStatement there either. See below.
</pre>
</blockquote>
<pre wrap="">
His original JSON output does, though,</pre>
</blockquote>
<br>
Ah, I totally missed that. So the ePPN is fundamentally getting
resolved.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:F663D6C2-78C4-465E-BB3E-3FABC508174B@osu.edu">
<pre wrap=""> and it raises more confusion because that looks like the output of the V3 AACLI (the JSON format), but the command line includes options specific to V2, so without more information I don't know what's going on.</pre>
</blockquote>
<br>
It's been awhile, I had to review the v3 aacli. Assuming you're
talking about the --configDir arg: The presence of that invalid arg
doesn't seem to cause the v3 aacli to barf. It just ignores it. So
I think that's just user (semi)error, and he's probably using v3
exclusively here. Red herring.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:F663D6C2-78C4-465E-BB3E-3FABC508174B@osu.edu">
<pre wrap="">
In any case, in V3 the JSON output is essentially going to tell you what raw data *would* be in the SAML if you have the proper attribute encoders in place, and what was posted seemed to me to have the appropriate encoders.</pre>
</blockquote>
<br>
Since the JSON says the attribute is fundamentally getting resolved
and released, but the SAML doesn't have it, doesn't that in fact
imply a problem with the SAML 2 encoder? The OP has:<br>
<br>
<br>
<tt><resolver:AttributeDefinition xsi:type="ad:Simple"
id="eduPersonPrincipalName"
sourceAttributeID="userPrincipalName"></tt><tt><br>
</tt><tt> <resolver:Dependency ref="myLDAP" /></tt><tt><br>
</tt><tt> <resolver:Dependency ref="myLDAP2" /></tt><tt><br>
</tt><tt> <resolver:AttributeEncoder
xsi:type="enc:SAML1ScopedString"
name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
encodeType="false" /></tt><tt><br>
</tt><tt> <resolver:AttributeEncoder
xsi:type="enc:SAML2ScopedString"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
friendlyName="eduPersonPrincipalName" encodeType="false" /></tt><tt><br>
</tt><tt></resolver:AttributeDefinition><br>
<br>
<br>
<br>
</tt>Looking at my test system, based on the example config we ship,
I have the following, which works:<br>
<br>
<tt><resolver:AttributeDefinition xsi:type="ad:Scoped"
id="eduPersonPrincipalName" scope="%{idp.scope}"
sourceAttributeID="uid"></tt><tt><br>
</tt><tt> <resolver:Dependency ref="myLDAP" /></tt><tt><br>
</tt><tt> <resolver:AttributeEncoder
xsi:type="enc:SAML1ScopedString"
name="urn:mace:dir:attribute-def:eduPersonPrincipalName" /></tt><tt><br>
</tt><tt> <resolver:AttributeEncoder
xsi:type="enc:SAML2ScopedString"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
friendlyName="eduPersonPrincipalName" /></tt><tt><br>
</tt><tt></resolver:AttributeDefinition></tt><tt><br>
</tt><br>
<br>
So does an encoder of SAML2ScopedString work with an
AttributeDefintion of type Simple, as the OP has it? Maybe that's
the problem. If he wants to base on 'userPrincipalName' (from AD,
etc), which is already a scoped string, maybe he needs to switch
encoder to type SAML2String? I always forget how the scoped vs
non-scoped stuff works.<br>
<br>
<br>
</body>
</html>