LDAP + IdP attribute issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

LDAP + IdP attribute issues

Riebeling, Sebastian

Hi,


I am having trouble releasing Attributes with my IdP.

I am trying to release Attributes with a LDAP data connector. I am using openldap and Shibboleth IdP Version 3.2.1.


I am trying to release the Attributes uid and sn from LDAP. I think in the logs the IdP says that it found these attributes (see below) and that the authentification succeeded. What else is necessary for the IdP to release the Attributes?

If the attributes gets correctly released I will get an prompt to accept the attributes after my login don't I?


What about the last line of the log: "invoking getAcceptedIssuers invoked" ? Is it an error and if so: What is wrong?




thanks for your time,


Sebastian


parts of my log:


2017-08-08 22:19:14,564 - DEBUG [org.ldaptive.SearchOperation:168] - execute response=[org.ldaptive.Response@2083676124::result=[org.ldaptive.SearchResult@165963062::entries=[[dn=uid=sriebeling,ou=People,dc=imib,dc=rwth-aachen,dc=de[[uid[sriebeling]], [sn[Riebeling]]], responseControls=null, messageId=-1]], references=[]], resultCode=SUCCESS, message=null, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1] for request=[org.ldaptive.SearchRequest@1058963531::baseDn=uid=sriebeling,ou=People,dc=imib,dc=rwth-aachen,dc=de, searchFilter=[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*), parameters={}], returnAttributes=[uid, sn], searchScope=OBJECT, timeLimit=0, sizeLimit=0, derefAliases=null, typesOnly=false, binaryAttributes=null, sortBehavior=UNORDERED, searchEntryHandlers=null, searchReferenceHandlers=null, controls=null, followReferrals=false, intermediateResponseHandlers=null] with connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1499402788::config=[org.ldaptive.ConnectionConfig@1096617956::ldapUrl=ldap://sso-med.imib.rwth-aachen.de, connectTimeout=3000, responseTimeout=-1, sslConfig=[org.ldaptive.ssl.SslConfig@1357220224::credentialConfig=net.shibboleth.idp.authn.impl.X509ResourceCredentialConfig@3f006a4c, trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, connectionInitializer=null], providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@393331654::metadata=[ldapUrl=ldap://sso-med.imib.rwth-aachen.de, count=1], environment={com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory}, providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@1233208020::operationExceptionResultCodes=[PROTOCOL_ERROR, SERVER_DOWN], properties={}, connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@132edfd8, controlProcessor=org.ldaptive.provider.ControlProcessor@4ba1b395, environment=null, tracePackets=null, removeDnUrls=true, searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null], sslSocketFactory=[org.ldaptive.ssl.TLSSocketFactory@864542371::factory=sun.security.ssl.SSLSocketFactoryImpl@2a7144e6, sslConfig=[org.ldaptive.ssl.SslConfig@1357220224::credentialConfig=net.shibboleth.idp.authn.impl.X509ResourceCredentialConfig@3f006a4c, trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null]], hostnameVerifier=null], providerConnection=org.ldaptive.provider.jndi.JndiStartTLSConnection@6925249e]
2017-08-08 22:19:14,572 - DEBUG [org.ldaptive.auth.SearchEntryResolver:418] - resolved result=[org.ldaptive.SearchResult@165963062::entries=[[dn=uid=sriebeling,ou=People,dc=imib,dc=rwth-aachen,dc=de[[uid[sriebeling]], [sn[Riebeling]]], responseControls=null, messageId=-1]], references=[]] for criteria=[org.ldaptive.auth.AuthenticationCriteria@985076411::dn=uid=sriebeling,ou=People,dc=imib,dc=rwth-aachen,dc=de, authenticationRequest=[org.ldaptive.auth.AuthenticationRequest@2130978129::user=sriebeling, retAttrs=[uid, sn]]]
2017-08-08 22:19:14,572 - INFO [org.ldaptive.auth.Authenticator:259] - Authentication succeeded for dn: uid=sriebeling,ou=People,dc=imib,dc=rwth-aachen,dc=de
2017-08-08 22:19:14,582 - DEBUG [org.ldaptive.auth.Authenticator:284] - authenticate response=[org.ldaptive.auth.AuthenticationHandlerResponse@581021354::connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1499402788::config=[org.ldaptive.ConnectionConfig@1096617956::ldapUrl=ldap://sso-med.imib.rwth-aachen.de, connectTimeout=3000, responseTimeout=-1, sslConfig=[org.ldaptive.ssl.SslConfig@1357220224::credentialConfig=net.shibboleth.idp.authn.impl.X509ResourceCredentialConfig@3f006a4c, trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, connectionInitializer=null], providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@393331654::metadata=[ldapUrl=ldap://sso-med.imib.rwth-aachen.de, count=1], environment={com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory}, providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@1233208020::operationExceptionResultCodes=[PROTOCOL_ERROR, SERVER_DOWN], properties={}, connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@132edfd8, controlProcessor=org.ldaptive.provider.ControlProcessor@4ba1b395, environment=null, tracePackets=null, removeDnUrls=true, searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null], sslSocketFactory=[org.ldaptive.ssl.TLSSocketFactory@864542371::factory=sun.security.ssl.SSLSocketFactoryImpl@2a7144e6, sslConfig=[org.ldaptive.ssl.SslConfig@1357220224::credentialConfig=net.shibboleth.idp.authn.impl.X509ResourceCredentialConfig@3f006a4c, trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null]], hostnameVerifier=null], providerConnection=org.ldaptive.provider.jndi.JndiStartTLSConnection@6925249e], result=true, resultCode=SUCCESS, message=null, controls=null] for dn=uid=sriebeling,ou=People,dc=imib,dc=rwth-aachen,dc=de with request=[org.ldaptive.auth.AuthenticationRequest@2130978129::user=sriebeling, retAttrs=[uid, sn]]
2017-08-08 22:19:14,587 - INFO [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:139] - Profile Action ValidateUsernamePasswordAgainstLDAP: Login by 'sriebeling' succeeded
2017-08-08 22:19:15,984 - DEBUG [org.ldaptive.ssl.AggregateTrustManager:129] - checkServerTrusted for sun.security.ssl.X509TrustManagerImpl@6be04c2f succeeded
2017-08-08 22:19:15,984 - DEBUG [org.ldaptive.ssl.AggregateTrustManager:157] - invoking getAcceptedIssuers invoked for sun.security.ssl.X509TrustManagerImpl@6be04c2f



My ldap.properties:

## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthenticator
idp.authn.LDAP.authenticator                   = anonSearchAuthenticator

## Connection properties ##
idp.authn.LDAP.ldapURL                          = ldap://sso-med.imib.rwth-aachen.de
idp.authn.LDAP.useStartTLS                     = true
idp.authn.LDAP.useSSL                          = false
#idp.authn.LDAP.connectTimeout                  = 3000

## SSL configuration, either jvmTrust, certificateTrust, or keyStoreTrust
idp.authn.LDAP.sslConfig                       = certificateTrust
## If using certificateTrust above, set to the trusted certificate's path
idp.authn.LDAP.trustCertificates                = /etc/ssl/private/sso-med-zert.pem
#idp.authn.LDAP.trustCertificates                = /home/sriebeling/ldap/ssl/sso-med1-zert.pem
## If using keyStoreTrust above, set to the truststore path
#idp.authn.LDAP.trustStore                       = %{idp.home}/credentials/ldap-server.truststore

## Return attributes during authentication
## NOTE: there is a separate property used for attribute resolution
#idp.authn.LDAP.returnAttributes                 = passwordExpirationTime,loginGraceRemaining
idp.authn.LDAP.returnAttributes                 = uid,sn


## DN resolution properties ##

# Search DN resolution, used by anonSearchAuthenticator, bindSearchAuthenticator
# for AD: CN=Users,DC=example,DC=org
idp.authn.LDAP.baseDN                           = ou=People,dc=imib,dc=rwth-aachen,dc=de
idp.authn.LDAP.subtreeSearch                   = true
idp.authn.LDAP.userFilter                       = (uid={user})
# bind search configuration
# for AD: idp.authn.LDAP.bindDN=[hidden email]
idp.authn.LDAP.bindDN                           = cn=admin,dc=imib,dc=rwth-aachen,dc=de
idp.authn.LDAP.bindDNCredential                 = secret

# Format DN resolution, used by directAuthenticator, adAuthenticator
# for AD use idp.authn.LDAP.dnFormat=%[hidden email]
idp.authn.LDAP.dnFormat                         = uid=%s,ou=people,dc=example,dc=org

# LDAP attribute configuration, see attribute-resolver.xml
# Note, this likely won't apply to the use of legacy V2 resolver configurations
idp.attribute.resolver.LDAP.ldapURL             = %{idp.authn.LDAP.ldapURL}
idp.attribute.resolver.LDAP.baseDN              = %{idp.authn.LDAP.baseDN:undefined}
idp.attribute.resolver.LDAP.bindDN              = %{idp.authn.LDAP.bindDN:undefined}
idp.attribute.resolver.LDAP.bindDNCredential    = %{idp.authn.LDAP.bindDNCredential:undefined}
idp.attribute.resolver.LDAP.useStartTLS         = %{idp.authn.LDAP.useStartTLS:true}
idp.attribute.resolver.LDAP.trustCertificates   = %{idp.authn.LDAP.trustCertificates:undefined}
idp.attribute.resolver.LDAP.searchFilter        = (uid=$resolutionContext.principal)
idp.attribute.resolver.LDAP.returnAttributes    = *+


My attribute-filter:

<AttributeFilterPolicy id="SSOMED">
        <PolicyRequirementRule xsi:type="Requester" value="https://sso-med1.imib.rwth-aachen.de/shibboleth" />

        <AttributeRule attributeID="uid">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>



         <AttributeRule attributeID="sn">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
    </AttributeFilterPolicy>
 


parts of my attribute-resolver:


 <resolver:AttributeDefinition id="uid" xsi:type="ad:Simple" sourceAttributeID="uid">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:uid" encodeType="false" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" encodeType="false" />
    </resolver:AttributeDefinition>

    <resolver:AttributeDefinition xsi:type="ad:Simple" id="sn" sourceAttributeID="sn">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sn" encodeType="false" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.4" friendlyName="sn" encodeType="false" />
    </resolver:AttributeDefinition>


<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="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>







--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: LDAP + IdP attribute issues

Riebeling, Sebastian

I have attached some more lines of the log..





--
To unsubscribe from this list send an email to [hidden email]

ldapprocess.log (69K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LDAP + IdP attribute issues

Cantor, Scott E.
In reply to this post by Riebeling, Sebastian
There is nothing about attribute resolution in either of the logs you posted. The attribute resolver itself doesn't log much of anything on INFO, so you're basically seeing nothing of relevance here to debug an attribute issue other than a lack of actual errors.

The logs are full of noise of immaterial bits of LDAP connectivity, which you should turn down if you want to get anything useful out when it's turned up.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LDAP + IdP attribute issues

Jeffrey Crawford
Two quick things, one I noticed that there is an entry "returnAttributes=[*+]" which looks like one string of "*+" instead of two distinct requested attributes of "*" and "+" separated by a space, so if that's the case you are probably not getting any attributes back from the search other than dn which is always returned (I think). 

also I want to point out that on the SP side i think by default both uid and sn are commented out in the /etc/shibboleth/attribute-map.xml file so even if you do send them, the SP still has to decode them.

Hope that helps

Jeffrey E. Crawford
Enterprise Service Team[hidden email]
    ^         ^
   / \  ^    / \    ^
  /   \/ \  /   \  / \
 /        \/     \/   \
/                      \

You have been assigned this mountain to prove to others that it *can* be moved.

On Tue, Aug 8, 2017 at 2:03 PM, Cantor, Scott <[hidden email]> wrote:
There is nothing about attribute resolution in either of the logs you posted. The attribute resolver itself doesn't log much of anything on INFO, so you're basically seeing nothing of relevance here to debug an attribute issue other than a lack of actual errors.

The logs are full of noise of immaterial bits of LDAP connectivity, which you should turn down if you want to get anything useful out when it's turned up.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]


--
To unsubscribe from this list send an email to [hidden email]
Loading...