LDAP Connection

[Ogunleye, Philip]

Hi Peter,

I didn't provide the log, was investigating myself.  For reference here
is the extract:

14:41:38.509 - DEBUG
[edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMD
RelyingPartyConfigurationManager:157] - No custom or group-based relying
party configuration found for https://snaponglobal.com/SAML. Using
default relying party configuration.
14:41:38.509 - DEBUG
[org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:253] -
Checking child metadata provider for entity descriptor with entity ID:
https://readw7PhilipO.snaponglobal.com/idp/shibboleth
14:41:38.509 - DEBUG
[org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:518] -
Searching for entity descriptor with an entity ID of
https://readw7PhilipO.snaponglobal.com/idp/shibboleth
14:41:38.509 - DEBUG
[org.opensaml.saml2.binding.AuthnResponseEndpointSelector:99] -
Filtering peer endpoints.  Supported peer endpoint bindings:
[urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign,
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST,
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact]
14:41:38.509 - DEBUG
[org.opensaml.saml2.binding.AuthnResponseEndpointSelector:65] -
Selecting endpoint by ACS index '0' for request '1EA1E29E7DD0F' from
entity 'https://snaponglobal.com/SAML'
14:41:38.509 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler
:283] - Authentication request contained a subject with a name
identifier, resolving principal from NameID
14:41:38.509 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2Prof
ileHandler:539] - Resolving principal name for subject of SAML request
'1EA1E29E7DD0F' from relying party 'https://snaponglobal.com/SAML'
14:41:38.509 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.
ShibbolethAttributeResolver:201] - Resolving principal name from name
identifier of format:
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
14:41:38.509 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.
ShibbolethAttributeResolver:222] - Using principal connector
saml2Transient to resolve principal name.
14:41:38.509 - WARN
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2Prof
ileHandler:551] - Error resolving principal name for SAML request
'1EA1E29E7DD0F' from relying party 'https://snaponglobal.com/SAML'.
Cause: No information associated with transient identifier: hk3585
14:41:38.509 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHand
ler:778] - Encoding response to SAML request 1EA1E29E7DD0F from relying
party https://snaponglobal.com/SAML
14:41:38.509 - DEBUG
[org.opensaml.ws.message.encoder.BaseMessageEncoder:49] - Beginning
encode message to outbound transport of type:
org.opensaml.ws.transport.http.HttpServletResponseAdapter
14:41:38.509 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:124] - Invoking
Velocity template to create POST body
14:41:38.525 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:158] - Encoding
action url of 'http://readw7PhilipO:9292/TestServlet/TestPost' with
encoded value
'http://readw7PhilipO:9292/TestServlet/Tes
tPost'
14:41:38.525 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:161] - Marshalling
and Base64 encoding SAML message
14:41:38.525 - DEBUG
[org.opensaml.ws.message.encoder.BaseMessageEncoder:97] - Marshalling
message
14:41:38.525 - DEBUG
[org.opensaml.saml2.binding.encoding.HTTPPostEncoder:184] - Setting
RelayState parameter to:
'http://readw7PhilipO:9292/TestServlet/TestPost', encoded as
'http://readw7PhilipO:9292/TestServlet/Tes
tPost'
14:41:38.540 - DEBUG
[org.opensaml.ws.message.encoder.BaseMessageEncoder:56] - Successfully
encoded message.
14:41:38.540 - INFO [Shibboleth-Audit:989] -
20130115T144138Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|1EA1E29E
7DD0F|https://snaponglobal.com/SAML|urn:mace:shibboleth:2.0:profiles:sam
l2:sso|https://readw7PhilipO.snaponglobal.com/idp/shibboleth|urn:oasis:n
ames:tc:SAML:2.0:bindings:HTTP-POST|_daf8c0b2ea2ebb8c6460fda13926b9bc|hk
3585|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||
||

I'm assuming it's related to my attribute config files, just checking
what's wrong.

Regards.

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
On Behalf Of Peter Schober
Sent: 15 January 2013 15:06
To: users at shibboleth.net
Subject: Re: LDAP Connection

* Ogunleye, Philip <Philip.Ogunleye at snapon.com> [2013-01-15 15:54]:
> Thanks for your help, I looked a little further and found the issue, 
> although setup correctly in the directory the uid is not part of the 
> dn so the lookup on the uid was failing.

Fyi, there's no requirement in LDAP to only search on attributes which
are part of the DN. Searching for any existing attribute would return
the object.

> I amended the filter to search by cn={0} and this has resolved that 
> issue.  It is finally authenticating, I will be writing out a document

> for my team to ensure that nobody else suffers the pain that I've just

> been through, I expect it's a bug in the version of the Apache 
> Directory Service.

Not returning the the object could also be missing a ACL/ACI or possibly
even a missing index (though that should only cause performance
degradation).

> I am now getting back a response, albeit a failure one for a strange 
> reason as the principal cannot be found.  Despite the logs indicating 
> that it has found the user it says it cannot, I'll look into this and 
> have this resolved.

Did you already provide the exact error log somewhere (because it's not
attached to this message of yours), -peter
--
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net