Alistair and others,

Speaking as a member of the SDSS support team, I'm not aware that the 
federation has an official line expecting entities to migrate to SAML2, 
although we would certainly strongly encourage anyone operating a 
Shibboleth 1.3.x entity to upgrade to Shibboleth 2.x ASAP.

I should also point out that "Shibboleth" and "SAML1" are not synonymous 
terms. Shibboleth is the name of specific software that implements the 
SAML protocol. Shibboleth 1.3.x versions support SAML1. Shibboleth 2.x 
versions support both SAML1 and SAML2.

As the Shibboleth 2.x IdP and SP both support both SAML1 and SAML2, if 
an entity deployer chooses not to support SAML2 endpoints then that is 
their decision. We don't recommend that, however, and it would not do 
anything to work around the issue that David Beaumont described on the 
page referred to earlier at:

http://www.jiscmu.ac.uk/news/view/188

That issue does *not* occur because SAML2 is being used. It occurs when 
SAML1 is being used, and the IdP releases both old and new forms of 
eduPersonTargetedID, according to the federation's recommendations, and 
the SP (which is probably Shibboleth 2.x) has been configured so that it 
automatically converts the old form to the IdP!SP!hash-value encoding. 
This results in the corresponding SP header variable having a semi-colon 
separated list of two identical persistent ID values in that form. The 
SP application needs to be able to handle this. Alternatively it may be 
easier for the SP operator to configure it so that it reads the two 
different forms of ePTID into two separate variables, and have the 
application choose one of them. Either configuration is straightforward 
for the Shibboleth 2.x SP and the choice probably depends on how the 
application is coded.

So failing to advertise SAML2 support in either or both of the SP or the 
IdP does not solve this. The IdP operator could make the decision not to 
release both forms of the attribute, but they may then run into problems 
with SPs that don't understand one or other form. This situation has 
occurred as a result of the problems described in the link that Peter 
Schober posted earlier at:

https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID

It shouldn't happen for older SPs that don't understand the new form. We 
are most likely to see this with Shibboleth 2.x SPs, and I would expect 
the majority of SP operators would take account of it during the upgrade 
process. I would encourage any SP operators who are not sure how to 
handle it to contact us for technical support via the UK federation 
service desk. I would also encourage any IdP operators who encounter 
this problem with particular SPs to contact us, and we will do our best 
to advise as appropriate.

Regards,

Sara Hopkins
SDSS Support Team
EDINA, University of Edinburgh

On 25/01/2011 11:57, Alistair Young wrote:
> Is there an official line from the Federation regarding migration? Will "Shibboleth", i.e. SAML1 be available for the foreseeable or are all entities expected to migrate to SAML2 at some point?
>
> ------------------------------------
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal Mòr Ostaig
>
>
>
>
> On 25 Jan 2011, at 11:30, David Beaumont wrote:
>
>> Hi Alistair,
>>
>> This was our experience from the service provider side: http://www.jiscmu.ac.uk/news/view/188
>>
>> The same IdP upgrade broke access to some other services:
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=JISC-SHIBBOLETH;2026c7d4.1007
>>
>> Dave
>>
>>> -----Original Message-----
>>> From: Discussion list for Shibboleth developments [mailto:JISC-
>>> [log in to unmask]] On Behalf Of Alistair Young
>>> Sent: 25 January 2011 11:06
>>> To: [log in to unmask]
>>> Subject: Moving to SAML2
>>>
>>> Has anyone experienced personalisation problems when upgrading to Shib
>>> 2? I believe Shib 2 advertises SAML2 instead of Shibboleth as default,
>>> so the attributes released bear no resemblance to Shibboleth
>>> attributes. In particular, eduPersonTargetedID has no Scope in SAML2
>>> and I think SPs use this as part of the personalisation process.
>>>
>>> I also believe a lot of SPs are still using Shib 1 software which
>>> doesn't know about SAML2 so a lot of personalisation problems might be
>>> masked until they upgrade.
>>>
>>> Just trying to gauge what might happen when advertising SAML2
>>> capability in an IdP. e.g. would users have to backup their RefWorks
>>> settings in case RefWorks doesn't something different with SAML2
>>> attributes and they lose everything?
>>>
>>> thanks,
>>>
>>> Alistair
>>>
>>>
>>> ------------------------------------
>>> Alistair Young
>>> Senior Software Engineer
>>> UHI@Sabhal Mòr Ostaig
>

-- 
Sara Hopkins
SDSS Support Team
EDINA, University of Edinburgh

The University of Edinburgh is a charitable body, registered in 
Scotland, with registration number SC005336.