Shibboleth Developers

[Adam Lantos <>]

Okay, I understand this.

When someone wants to use ComputedId (edupersontargetedid-style) as a
SAML2 persistent NameID, one need to implement a custom
principalconnector for this? Wouldn't it be a lot easier to just
store/cache all nameid information in the session store and look up
principal name by nameid-sessionindex? If the session was indexed by
the nameid value, back-channel code could easily look up the correct
session IMHO.


On Tue, Jul 21, 2009 at 3:29 PM, Chad La 
Joie<>
 wrote:
> Technically the IdP isn't just an IdP.  It plays the IdP and AA roles in
> SAML terminology.  When it come to queries there may be no session.  At
> which point the application still has to know how to get the principal name
> in order to look up the attributes and answer the query.
>
> Adam Lantos wrote:
>>
>> Hi,
>>
>> I've one quick question on idp session handling:
>>
>> AbstractSAML2ProfileHandler.populateUserInformation() tries to look up
>> session by nameid value. This fails with most nameids because the idp
>> session is not indexed by nameid. Then the code resolves principal
>> name via principal connectors and retrieves session by principal name.
>> Wasn't it cleaner to have index on the session for every nameid (this
>> of course would need unique nameids)? Then the principal connector
>> -stuff would be completely unnecessary, right? Or I'm just overlooking
>> something here...
>>
>>
>> thanks,
>>  Adam
>
> --
> 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
> ,
>  http://www.switch.ch
>
>