Re: Using cn (commonName) as NameID

[Robo Burned]

 Tommy, you are right. I am not adding data connector in resolver Dependency. The uid attribute is defined without any references to the data connector and I supposed connectors were used in v2.
So I will need to add data connector as described in example here and add cn to ReturnAttributes list. 
https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector
Will try tomorow.
Forgot to point this in first email. I also configured NameId to use cn value in saml-nameid.xml in the shibboleth.SAML2NameIDGenerators list

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
 p:attributeSourceIds="#{  {'cn'} }" />
Reference to issue  https://issues.shibboleth.net/jira/browse/IDP-871

>Вторник, 24 ноября 2015, 15:29 UTC от "Doan, Tommy" <tdoan at smu.edu>:
>
>I believe Robo is missing the reference to a data connector in his attribute definition. Below is how we use CN in case it helps. 
>
>attribute-resolver.xml
><resolver:AttributeDefinition xsi:type="ad:Simple" id="commonName" sourceAttributeID="cn">
>  <resolver:Dependency ref="myLDAP" />
>  <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:cn" />
>  <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.3" friendlyName="cn" />
></resolver:AttributeDefinition>
>
>attribute-filter.xml
><afp:AttributeFilterPolicy id="releaseExample" >
>  <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://example.edu/shibboleth" />
>  <afp:AttributeRule attributeID="commonName">
>  <afp:PermitValueRule xsi:type="basic:ANY" />
>  </afp:AttributeRule>
> </afp:AttributeFilterPolicy


Robo Burned
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151124/d7552ca5/attachment.html>