...
This means that the user’s attributes will be included with the authentication assertion that is returned to the SP in the initial POST transaction. This will reduce one network round trip between the SP and the IdP.
a.
Bob has confirmed that the existing SPs will accept the push without requiring any changes to be made to any of the existing SP configurations.b. We will be removing the artifact query support from the MIT metadata. Need to determine when this change will be made.c.
(completed, week of 10/19/2009)Bob will check to make sure that no SPs are using artifact query, and perform test to ensure that the removal does not break anything. (week of 10/19/2009)5.
Pre-idp 2.1 deployment changes to the existing 1.3 IdPs
...
- Update the Apache server on the existing 1.3 IdPs to include the mod_rewrite module. This will require a rebuilding of Apache on RHEL3. Idp2-dev will be used. This is expected to take approximately one week.
...
- A second instance of the 1.3 IdP software will be installed on the existing IdPs. The new instances will support the new endpoint naming convention.
...
- Idp2-dev will be used for testing this prior to deployment to either staging or production.
...
- Test phase:
...
- This will include the new IdP instances, with the new endpoints running on the IdP staging servers.
...
- We will want some of our most heavily used SP customers to help with testing. We would like Stellar and Wikis staging and test instances to point to the core staging environment during this phase.
...
IDP 2.x deployment issues
entityIDs
a. There are currently two entityIDs or proiderIDs that are used to describe the core MIT IdPs. Within InCommon our entityID is urn:mace:incommon:mit.edu Within the campus federation our entityID is *https://idp-mit-edu.ezproxy.canberra.edu.au/shibboleth*. A single entityID can be used in two different federations. However, when doing so it is important to keep the data identical in the two different metadata files.
...
https://spaces.internet2.edu/display/InCCollaborate/IdP+entityID+Shift+to+URLs+--+FAQ indicates that new IdPs should use a URL style entityID. However, it also suggests that existing URN style entityID should not be migrated. It points out, “Changing an entityID may cause service disruption and require changes at many partner SP sites. It is usually more important for entityIDs to remain stable.”
We should strongly consider ignoring this recommendation and migrating to the URL form of entityID within the InCommon metadata.
deployment migration and temporary SSO disruption
b. We’re thinking about adding the new IdPs to the existing idp.mit.edu DNS round robin. It should be understood that there will be no state sharing between the 1.3 IdPs and the 2.x IdPs. To a certain extent this will affect SSO. For users that have configured their browsers to always use a certificate, or always use Kerberos, there should be no visible change in behavior while the 1.3 and 2.x servers are both running.
...
Should the DNS TTL be lowered, during the time that both the 1.3 and 2.x IdPs are running concurrently?
Alternatives:
1. Bring up the new IdPs under a new DNS name, and add them to the MIT-metadata. As SPs take the new metadata, they will start using the new IdPs.
...
Note that this technique is not recommended by the Shib-user community or the Internet2 wiki. It can lead to a long transition time, and it is difficult to backtrack quickly if there are any problems. The best behaved SPs tend to only update their metadata once a day, many only update manually.
2. We could “throw the switch” and shut down the old IdPs and bring up the new IdPs during one scheduled short down time. This would require a short interruption of service. If there are problems with the 2.x IdPs it will mean there will be other interruptions of service.
...