> You seem to be contradicting yourself. If the WAYFless URL forces "Shibboleth", ie. SAML1, then according to your own reasoning your personalisations should be untouched.
by this I mean, as we're not using a shib IdP our Shibboleth SSO endpoint doesn't change once we support SAML2. So our SSO hard coded WAYFless URLs should still work. I was referring to the entityID based WAYFless URLs you mentioned. They could very well break overnight after an SP SAML2 upgrade. Where once they were using Shibboleth endpoints, they would now use SAML2 endpoints and hence get different attributes.
> The Shibboleth 2 SP can be configured to convert the attributes to various different encodings. From that point it is indeed up to the application how they are used, and some applications may well not be handling them in the best way.
and the plethora of non "shibboleth" SPs in the federation.
> the IdP's scope are all available in the assertion
AFAICS there isn't a scope on 1.3.6.1.4.1.5923.1.1.1.10 (eptid) in SAML2. The nearest you can get is NameID#NameQualifier which suggests metadata lookup which won't work as an IdP can assert multiple scopes. I'm slowly starting to understand the SP side of things in shib 2.x where it "de-botches" eptid:
https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID#NativeSPTargetedID-2.xBranch
> This is a long way from saying that SAML2 is guaranteed to break personalisations
not SAML2 per se but how it's interpreted. Saving personalisations seems to be a combination of factors. What the IdP is already releasing as a "shibboleth" IdP and how the SP is interpreting those attributes. It seems that if an IdP releases SAML2 attributes as part of a SAML1.1 profile then it might be ok.
From what I've read so far on this thread (and it's a really helpful thread btw) it's a 50/50 split between losing and preserving personalisations.
------------------------------------
Alistair Young
Senior Software Engineer
UHI@Sabhal Mòr Ostaig
On 26 Jan 2011, at 13:13, Sara Hopkins wrote:
> On 26/01/2011 11:46, Alistair Young wrote:
>
>> Andy, it's based on my discussions with/readings about some SPs where
>> eptid scope+value is used for personalisations. As there is no scope in
>> SAML2 I can't see how personalisations can be preserved across a migration.
>
> It is *easy* to convert between the scoped form of ePTID and the unscoped IdP!SP!hash-value form, as the entity IDs of the IdP and SP and the IdP's scope are all available in the assertion.
>
>> By "breaking urls" I meant the personalisations. i.e. one day you're
>> accessing via Shibboleth and you have your settings. The next, it's
>> SAML2 and the SP doesn't know who you are. WAYFless URLs generally seem
>> to force Shibboleth so in effect there's no migration occurring.
>
> You seem to be contradicting yourself. If the WAYFless URL forces "Shibboleth", ie. SAML1, then according to your own reasoning your personalisations should be untouched.
>
> How WAYFless URLs work depends on the SP. For example, the Shibboleth 2 SP can be configured to support SAML1-only WAYFless URLs, or WAYFless URLs that will choose SAML2 support if SAML2 support is advertised by the IdP metadata, but will fall back to SAML1 if the IdP does not advertise SAML2.
>
>> eptid value is the same across shib and saml2 for us too but my
>> experience of SPs is "shibboleth" gets them the attributes and it's up
>> to them how they use them.
>
> The Shibboleth 2 SP can be configured to convert the attributes to various different encodings. From that point it is indeed up to the application how they are used, and some applications may well not be handling them in the best way.
>
> This is a long way from saying that SAML2 is guaranteed to break personalisations, though.
>
> Sara
> --
> Sara Hopkins
> SDSS Support Team
> EDINA, University of Edinburgh
>
> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
|
