Shibboleth Developers

[Peter Williams <>]

If the idp gets a cert credential with mulitiple subject name  
alternatives (dn from v1 field, dns name and upn and foafssl webid  
from 1 v3 San field, ...) should it create multiple principals (and  
create a compound saml subject)?



On Apr 1, 2010, at 6:18 AM, "Chad La Joie" 
<>
 wrote:

>
> On 4/1/10 8:47 AM, Paul Hethmon wrote:
>> On 4/1/10 6:14 AM, "Chad La Joie " 
>> <>
>>  wrote:
>>
>>> Now, Subject treats Principals as a set (i.e. unordered, no  
>>> duplicates,
>>> no null).  So when getPrincpalName is called, on the session, the  
>>> first
>>> of an unordered collection is returned.  So, I'm guessing, if you  
>>> look
>>> in to the Subject you'll see two UsernamePrincipals, one saying  
>>> 'user1'
>>> and one saying 'user2'.  Which is exactly what you told the IdP was
>>> supposed to happen.
>>
>> And that's what I figured out a few minutes later.
>>
>> What I'd like to understand is why that behavior?
>
> Because there is no single principal name for a person.  This is  
> easy to
> see with different types of authentication methods (i.e. the subject  
> DN
> from a client-cert is obviously different than a username used with a
> password) but there are also people (wrongly, in my opinion) who  
> issues
> their users multiple credentials of the same type and try to use  
> that to
> distinguish which "role" the user is operating in.  So a user ends up
> with their "everyday" account and their "payroll manager" account, or
> whatever, and both are username/passwords.
>
> Trust me, I'd love to simplify the login code so that only one type of
> authentication method was ever allowed and that that one type only  
> ever
> had a single way of identifying the user.  It would make the code much
> easier.  But that's not reality.
>
>> In my case, because of bad user habits, its not doing the right  
>> thing and
>> I've got to change it in some way. A quick test shows that I can  
>> null out
>> the IdP session object in the http request and get what I need.  
>> That just
>> leaves lingering doubts on whether that's the right way.
>
> Sorry, but this is complete bollocks.  There is no technical  
> solution to
> bad user habits.  Logout doesn't work.  We've said that again and  
> again
> and to date every person who has tried to make it work just ends up
> proving the point.  The SLO plugin produced for Shib and the SLO
> features of other products, all of which claim to work, do in fact  
> work
> as long as nothing ever goes wrong.  But again, that's not reality.
>
>
>
> -- 
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered