>>> On 11/01/2010 at 11:03, in message
<[log in to unmask]>, "M.Slowe"
<[log in to unmask]> wrote:
> Morning all,
>
> I've just been reading over the process of upgrading our service offering
> from Old-and-busted Shib1.3 IdP to a New-Hotness Shib2.x and couldn't quite see
> the point of the cross-over period where you have your old IdP configured to
> answer queries on the Shib2 endpoints.
>
> Having read
> http://www.ukfederation.org.uk/content/Documents/RollingIdPUpgrade and liking
> the sound of option (b):
>
> This conserves the entityID but has this disadvantage: until the metadata
> has propagated to a given SP, that SP will not be able to communicate with
> the new IdP.
> }}}
>
> What I don't understand is why, in the overview of the Edina migration, they
> went to the trouble of configuring the old IdP to listen on the Shib2
> endpoints for a while. Could someone enlighten me?
I think Edinburgh did it this way because they don't have apache at the front end? Rod will be able to comment
From my own experience of upgrading before christmas you really want to be able to listen for SPs who are coming in from the old metadata and the new, this is because it took some SPs a week from the metadata change to start going to the 2.1 IdP.
I would like to propose an alternative approach which I used which you can do if you have apache at the front (thanks to Adrian Barker who first suggested it). We have two IdPs, an in service one and a backup, these are named internally IdP1 and IdP2, the DNS is set to point idp.dundee.ac.uk at either of them and they both have identical configuration (entityID etc).
IdP1 was left unchanged as a 1.3 IdP, IdP2 was upgraded with new JAVA, new Tomcat and 2.1 IdP was installed on it. For initial testing a new entityID was set on it and it was verified as fully functional and then the entity ID was set to the same as the one on IdP1.
Then, an additional proxypass was added to the apache on IdP1 to send the shibboleth 2 endpoints (/idp) over to the tomcat on IdP2. The metadata was then changed. All SPs would continue to arrive at IdP1's apache but those who had picked up the new metadata would then get shunted off to the shib2 IdP on IdP2 while those with the old metadata would arrive with /shibboleth-idp endpoints and would continue to be serviced by the shib 1 IdP on IdP1.
This worked beautifully and for the transition we were able to handle the quick people (BMJ started using shib 2 45 minutes after the change over!) and the rather more tardy who took a week to change. The only hitch were a couple of rather broken sites who seemed to be using an SP that had metadata in two places, these would authenticate at the shib 1 IdP and then go off to the shib2 IdP to ask for attributes or vice versa :-( That aint going to work......
Eventually when everyone was happily coming through with shib 2 endpoints and shib 1 traffic had stopped the DNS was switched over and yes, some 3 weeks plus after the DNS change there is still one SP who is coming to the wrong host..... There's no point telling them, I've upgraded IdP1 to shib 2 now and am about to switch the DNS back again.
I was asked if I'd write this up for the fed site and was in the process of doing so when a family bereavement put a halt to everything, but I'm back in harness now and will get it sorted asap.
I am told that its possible to have all of the above on one machine, i.e. with two Tomcats listening on different ports, but this was getting too far from a completely "bog standard" configuration for me. The advantage of the above is that all ports are totally standard and so are all endpoints.
> One more question -- the eduPersonTargettedId (the magic salted unique value) --
> does the new IdP support the same EntityID+Salt algorithm? We're not
> currently storing the values that come out of there and are relying on
> EntityID+Username+Salt not changing (which, at the moment, they won't).
>
Yes. In fact entityID is not a factor, ePTID is just generated from the attribute+salt, so you will generate the same value even with a different entityID, of course SPs won't recognize you as the same with a different entityID. The following will give you everything you need to cover all bases:
<resolver:DataConnector xsi:type="ComputedId" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="computedID"
generatedAttributeID="computedID"
sourceAttributeID="anldapdirectoryattribute"
salt="blah blah blah">
<resolver:Dependency ref="myLDAP" />
</resolver:DataConnector>
<resolver:AttributeDefinition id="eduPersonTargetedID.old" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
scope="dundee.ac.uk" sourceAttributeID="computedID">
<resolver:Dependency ref="computedID" />
<resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonTargetedID" />
<resolver:AttributeEncoder xsi:type="SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonTargetedID" friendlyName="eduPersonTargetedID" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
sourceAttributeID="computedID">
<resolver:Dependency ref="computedID" />
<resolver:AttributeEncoder xsi:type="SAML1XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" />
<resolver:AttributeEncoder xsi:type="SAML2XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" />
</resolver:AttributeDefinition>
(don't forget to release both eptid and eptid.old in the arp filter)
HTH
Andy Swiffin
Dundee
The University of Dundee is a registered Scottish charity, No: SC015096
|
