Possible attribute problems when login

[Sergio Rivas]

Thank you Peter and Scott for your quick answers. I've checked both IdP and 
SP log files and I think there's no error on them (I've just started with 
Shibboleth, so excuse me because I may be wrong). Let me show you what I've 
found on my Service Provider when I had introduced a valid login and get the 
attribute error message:


shibd.log file
-----------------
2012-08-20 02:42:17 INFO Shibboleth.SessionCache [4]: new session created: 
ID (_40835646e26bd34f82155b2bce38a601) IdP 
(https://idp.semi.com/idp/shibboleth) 
Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (127.0.0.1)
2012-08-20 02:42:17 INFO Shibboleth.SessionCache [5]: removed session 
(_40835646e26bd34f82155b2bce38a601)


transaction.log file
------------------------
2012-08-20 02:42:17 INFO Shibboleth-TRANSACTION [4]: New session (ID: 
_40835646e26bd34f82155b2bce38a601) with (applicationId: default) for 
principal from (IdP: https://idp.semi.com/idp/shibboleth) at (ClientAddress: 
127.0.0.1) with (NameIdentifier: _047e0650c4482ea388d4ac9ea66ce019) using 
(Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: 
_173f7437614aca6d112c7a762d22e440)
2012-08-20 02:42:17 INFO Shibboleth-TRANSACTION [4]: Cached the following 
attributes with session (ID: _40835646e26bd34f82155b2bce38a601) for 
(applicationId: default) {
2012-08-20 02:42:17 INFO Shibboleth-TRANSACTION [4]:     sn (1 values)
2012-08-20 02:42:17 INFO Shibboleth-TRANSACTION [4]:     cn (1 values)
2012-08-20 02:42:17 INFO Shibboleth-TRANSACTION [4]: }


As you can see, the shibd.log file shows that the session is created and 
removed at the same time, while the transaction.log reveals that attributes 
"sn" and "cn" are received (I guess). Here's what I've found on my Identity 
Provider when introducing a valid login:


idp-process.log file
-------------------------
02:42:13.018 - INFO [Shibboleth-Access:73] - 
20120820T004213Z|192.168.0.201|idp.semi.com:443|/profile/SAML2/Redirect/SSO|
02:42:17.447 - INFO [Shibboleth-Access:73] - 
20120820T004217Z|192.168.0.201|idp.semi.com:443|/profile/SAML2/Redirect/SSO|
02:42:17.745 - INFO [Shibboleth-Audit:969] - 
20120820T004217Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_524610c606cf6fce49126e40baf33413|https://sp1.semi.com/shibboleth|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://idp.semi.com/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_c676f179925712728ab438368f2b230b|usuario|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|sn,cn,transientId,|_047e0650c4482ea388d4ac9ea66ce019||


idp-audit.log file
---------------------
20120820T004217Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_524610c606cf6fce49126e40baf33413|https://sp1.semi.com/shibboleth|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://idp.semi.com/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_c676f179925712728ab438368f2b230b|usuario|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|sn,cn,transientId,|_047e0650c4482ea388d4ac9ea66ce019||


There's no error here and in the other log files (Tomcat's one included). 
So, do you see anything wrong that could help?

Also, Scott, excuse me, could you give me more information please? I didn't 
caught what you were trying to explain me (sorry a lot, as I said, I'm 
beggining with Shibboleth).

Thank you again!

Kind Regards,
Sergio.



-----Mensaje original----- 
From: Peter Schober
Sent: Sunday, August 19, 2012 5:55 PM
To: users at shibboleth.net
Subject: Re: Possible attribute problems when login

* Sergio Rivas <srivasg_21 at hotmail.com> [2012-08-19 14:58]:
> I’ve reviewed all the configs and everything seems correct. I even
> tried “aacli.sh” script on IdP to check if it was releasing the
> attributes I selected correctly, and it seems to work (I get
> commonName + surname attributes with a correct user, and no
> attributes with an incorrect user).

Have a look in your log files. The IdP logs will tell you what the IdP
sent, the SPs logs will tell you what the SP recieved and what it did
with those attributes (mapping them, discarding them and why), which
you can then compare to your webserver authorization (authZ)
configuration.
You can also check the SP's native log for further details on why
authZ failed.
-peter
--
To unsubscribe from this list send an email to 
users-unsubscribe at shibboleth.net