Re: Using cn (commonName) as NameID

[Robo Burned]

I am setting up testing environment so secruity does not matter.
I removed  StartTLSTrustCredential from  resolver:DataConnector and now get the following error:
You said my Bind DN configuration is incorrect. I don't understand what are bind, base DNs are.
Caused by: javax.naming.OperationNotSupportedException: [LDAP: error code 53 - UNWILLING_TO_PERFORM: Bind failed: Cannot Bind for Dn OU=MSKCC_Users, DC=mskcc, DC=dom]
I am not sure why the same DN works with authentication and does not work for attribute resolution. However I changed DN settings to the following (Default for Apache DS)
idp.authn.LDAP.bindDN= uid=admin, ou=system
idp.authn.LDAP.bindDNCredential= secret
And... got no attributes: search returns no entities.
In logs I see
2015-11-25 20:20:52,061 - DEBUG [net.shibboleth.idp.attribute.resolver.dc.ldap.impl.TemplatedExecutableSearchFilterBuilder:212] - Template text (uid=$(resolutionContext.principal)) yields (uid=$(resolutionContext.principal))
I changed config to the following:
idp.attribute.resolver.LDAP.searchFilter= (uid=$requestContext.principalName)
And now it works!
Great thank you for assistence!
>Среда, 25 ноября 2015, 12:52 UTC от "Doan, Tommy" <tdoan at smu.edu>:
>
>I would leave useStartTLS disabled in ldap.properties as you get started, as you have done. (Before going into production of course you’ll want to have either
 that or useSSL enabled.) If you continue having certificate-related problems, you might try removing the StartTLSTrustCredential element from your data connector for the time being. Also note that your idp.authn.LDAP.bindDN is not currently set to the DN of
 an account. 
> 
>You may find the Shibboleth Workshop series documentation to be a very practical guide as you get started, particularly this section.
>https://spaces.internet2.edu/display/ShibInstallFest/Windows+Identity+Provider+IdPv3#WindowsIdentityProviderIdPv3-4.ConfigureUserAuthentication
> 
>From: users [mailto:users-bounces at shibboleth.net] On Behalf Of  Robo Burned
>Sent: Wednesday, November 25, 2015 5:28 AM
>To: Shib Users < users at shibboleth.net >
>Subject: Re: Using cn (commonName) as NameID
> 
>I am working on adding data connector to the attribute-resolver.xml I have no success with examples from documentation - they reference non-existing ldap.properties. So I started to workd with example from attribute-resolver-ldap.xml
 file
><resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
>ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
>baseDN="%{idp.attribute.resolver.LDAP.baseDN}" 
>principal="%{idp.attribute.resolver.LDAP.bindDN}"
>principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
>useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}">
><dc:FilterTemplate>
><![CDATA[
>%{idp.attribute.resolver.LDAP.searchFilter}
>]]>
></dc:FilterTemplate>
><dc:ReturnAttributes>%{idp.attribute.resolver.LDAP.returnAttributes}</dc:ReturnAttributes>
><dc:StartTLSTrustCredential id="LDAPtoIdPCredential" xsi:type="sec:X509ResourceBacked">
><sec:Certificate>%{idp.attribute.resolver.LDAP.trustCertificates}</sec:Certificate>
></dc:StartTLSTrustCredential>
></resolver:DataConnector>
>As by default, idp.attribute.resolver.LDAP.* properties values are referencing idp.authn.LDAP.* props.
>The props are quite default except useStartTLS = false. (see all props attached). 
>Now I am getting IllegalArgumentException: name  while setting bean property connectionFactory.sslConfig.credentialConfig.'trustCredential
>Do I need to disable SSL in some way? I see #idp.authn.LDAP.useSSL = false but I see no such setting /attribute for data connector
> 
>>Среда, 25 ноября 2015, 11:34 +01:00 от Peter Schober < peter.schober at univie.ac.at >:
>>* Robo Burned < robo at list.ru > [2015-11-25 10:40]:
>>> I found the following in docs:
>>> Attribute Retrieval
>>> LDAP attributes are returned as part of the authentication process and exposed in the LDAPResponseContext.
>>> By default, attributes will be searched for using the same connection the user authenticated on.
>>> I've added cn to both
>>> idp.authn.LDAP.returnAttributes= cn,passwordExpirationTime,loginGraceRemaining
>>> and 
>>> idp.attribute.resolver.LDAP.returnAttributes= cn,homephone,mail
>>
>>This is the comment above idp.authn.LDAP.returnAttributes in my
>>ldap.properties file:
>>
>>## Return attributes during authentication
>>## NOTE: this is not used during attribute resolution; configure that directly in the
>>## attribute-resolver.xml configuration via a DataConnector's <dc:ReturnAttributes> element
>>
>>To just get some data from LDAP into the IDP and release it either as
>>SAML Attribute or NameID you use the IDP as usual, configuring the
>>attribute resolver. The IDP ships will many fully functional examples.
>>Here's the documentation if you prefer to ignore those:
>>https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration
>>https://wiki.shibboleth.net/confluence/display/IDP30/AttributeDefinitionConfiguration
>>https://wiki.shibboleth.net/confluence/display/IDP30/DataConnectorConfiguration
>>
>>-peter
>>-- 
>>To unsubscribe from this list send an email to  users-unsubscribe at shibboleth.net
>
>
>С уважением,
>
>Robo Burned
>-- 
>To unsubscribe from this list send an email to  users-unsubscribe at shibboleth.net


С уважением,

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