[Shib-Users] principal name in session
Bobby Lawrence
When I authenticate with a username, the JAAS module authenticates me
against LDAP.
I'm returned my principals: <username>, <group>, <group2>, <group3>, etc
as a Set in my Subject.
However, after authentication, the IDP tries to get my attributes to
pass in the SAML assertion back to the SP.
Once this begins, I can see from the logs that the IDP is using one of
my group names as the principal and not my username.
Since the lookup of my attributes requires my username, the IDP doesn't
return any of my attributes.
I think this has to do with the underlying say that Principals are
stored in a Subject.
The Principals are stored as a Set, but when you try to retrieve the
principal name from the Session (in
edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession).
When you get the principal name, it simply gets an Iterator of the
prinicpals and returns the first one.
Well - the JRE doesn't make any guarantee's of the ordering of the
elements in the Set.
The Virginia Tech LDAP authenticator users a TreeSet for the principals of
So I think what I'm seeing is a product of this.
The IDP is retrieving the first element of a un-ordered Set and using
that as my principal name - even though it is not my username.
Has anyone else noticed this problem?
Is there a work around?
Bobby Lawrence
Here is a version that corrects some of the spelling/train of thought
issues from my original post:
I'm noticing some weird behavior when using the UsernamePassword login
type.
When I authenticate with a username, the JAAS module authenticates me
against LDAP using the Virginia Tech LDAP authenticator.
I'm returned my principals: <username>, <group>, <group2>, <group3>, etc
as a Set in my Subject.
However, after authentication, the IDP tries to get my attributes to
pass in the SAML assertion back to the SP.
Once this begins, I can see from the logs that the IDP is using one of
my group names as the principal and not my username.
Since the lookup of my attributes requires my username, the IDP doesn't
return any of my attributes.
I think this has to do with the underlying way that Principals are
stored in a Subject.
When you get the principal name from the Session (in
edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession),
it simply gets an Iterator of the prinicpals and returns the first one.
Well - the JRE doesn't make any guarantee's of the ordering of the
elements in the Set.
So I think what I'm seeing is a product of this.
The IDP is retrieving the first element of a un-ordered Set and using
that as my principal name - even though it is not my username.
Has anyone else noticed this problem?
Is there a work around?
----------------------------
Bobby Lawrence
MIS Application Developer
Jefferson Lab (www.jlab.org)
Email: rob...@jlab.org
Office: (757) 269-5818
Pager: (757) 584-5818
----------------------------
Bobby Lawrence
I got around this problem by using the RemoteUser login and configured
my app server to handle the login.
Seems to work now...the IDP is sending back my attributes as expected.
Scott Cantor
> type.
> When I authenticate with a username, the JAAS module authenticates me
> against LDAP using the Virginia Tech LDAP authenticator.
> I'm returned my principals: <username>, <group>, <group2>, <group3>, etc
> as a Set in my Subject.
Can't you just eliminate the part that's adding those groups as Principals?
I don't recall my use of that plugin doing that.
-- Scott
Bobby Lawrence
I kinda like this way better anyway because it follows our architecture better and I don't have to maintain a LDAP password in the config file (my app server is setup to do LDAP auth and it encrypts the password before storage locally).
---------------------------- Bobby Lawrence MIS Application Developer Jefferson Lab (www.jlab.org) Email: rob...@jlab.org Office: (757) 269-5818 Pager: (757) 584-5818 ----------------------------
Chad La Joie
which are Principals according to JAAS, you're saying that those things
identify the user in some capacity. It's then up to you to tell the
resolver what to do with this extra information. This would be equally
true if you offered multiple authentication types (e.g. username/pass
and X.509 client cert) and some set of SPs required one and another set
required the other. You'd end up with more than one Princpal for the
Subject.
It's confusing but it's also what you're telling the IdP to do. There
is no way it can determine which ID you tell it to pull is more
important than some other ID. The proper way to handle this is to make
sure your LDAP template is properly constructed. What "properly" means
is site dependent, but whatever the filter is it needs to uniquely
identify the user from the set of Principals that have been given to the
IdP.
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
Brent Putman
https://bugs.internet2.edu/jira/browse/SIDP-309
--Brent