Page History

...

1. 1. Idp1-staging.mit.edu
   2. Idp2-staging.mit.edu
   3. Foonalagoona.mit.edu (OPS/AMIT)

Develop login page(s) that support multiple mechanisms, without using Stanford WebAuth. (currently expect to complete by January 1st, 2010)

1. Authentication mechanisms:
   1. Username/password urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, This uses the Internet2 provided JAAS Kerberos module. the MIT specific UI still needs to be written.
   2. X.509 certificates (via Apache mod_ssl) urn:oasis:names:tc:SAML:2.0:ac:classes:SoftwarePKI
   3. Kerberos via http-spnego (via modgssapache) urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
2. login handler module development (to support the MIT page with multiple mechansim choices, as well as the ability for SPs to specificy a particular mechanism)
3. re-implement the iPhone support

The login page that presents all three of these mechanisms will be written in JSP. Work estimate is 2 to 3 weeks to have a proof of concept page. Another 1-2 weeks are estimated for the complete work, for a total of 3-5 weeks, with a fairly high confidene on 4 weeks.

High Availability plans

ShibHA is not available for the 2.x IdPs. The recommendation is to use Tomcat Terracotta. As of October 18^th Bob had not started working with Terracotta. Bob estimates that he will need approximately 3 days to become familiar with Terracotta configuration issues.
 
Paul will request two test machines from NIST (RHEL5 VMS). These will start as test machines and become the new staging machines.
 
DNS round robin is being used today, and we plan to continue using this for next phase of the project, despite Internet2s recommendation to use a hardware load balancer. We wish to avoid performing an SSL termination at the F5, especially since usernames and passwords are being sent to the IdPs in some cases.

...

1. (completed, week of 10/19/2009)Bob will check to make sure that no SPs are using artifact query
2. (week of 10/26/2009) perform test to ensure that the removal does not break anything.
3. Since EZProxy does not use the Internet2 Shibboleth distribution, and instead has a fully integrated SP distribution, additional testing will have to be coordinated with the MIT Libraries. (Paul to test 12/15 or 12/16)
4. Need to determine when this change will be made. (Currently planned for the week of 12/22/2009)

Migrate from SP attribute query to IdP attribute push.

...

1. 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. This time estimate includes the rebuilding of Apache, the installation on the test server, and testing the URL rewriting functionality. (completed on one dev machine (reported on 12/15))
2. Idp2-dev will be used for testing this prior to deployment to either staging or production.

 Alternate strategy: 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. This alternate will only be used if the URL rewriting strategy is a failure.

1. Test phase:
   1. This will include the modified IdPs , with the new endpoints supported on the IdP staging servers.
   2. The initial testing phase will simply demonstrate that we can use mod_rewrite to avoid the need to run a second instance of the 1.3 IdPs.
   3. 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. - (Can we get AMIT to commit to this during the week of January 4th? Paul will raise this at the 12/15 ISDA Pipeline meeting)

IDP 2.x deployment issues

entityIDs (There is no good way to transition the InCommon metadata, we plan to leave this as is. Bob does need to test the configuration that supports the two different entityIDs for MIT. He estimates this will take one day. The testing should be completed by January 1st.)

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.

...

We should strongly consider ignoring this recommendation and migrating to the URL form of entityID within the InCommon metadata. (Won't work.)

metadata updating 

Several of the MIT SPs do not currently follow our recommendations to update the MIT metadata on a regular basis. We need to get all SPs that are important to users and customers to update their metadata on a regular basis before the transition deployment can commence.

1. Complete draft of message to all SP administrators (Paul)
2. Send message to all SP administrators (Paul)
3. Do we have a way of verifying that SP administrators have taken action?
4. Draft message regarding IdP transition

On December 8th the metadata was updated with an expiration date of February 1, 2010.

Paul to send another reminder to stakeholders, and include information about how they can confirm they have the recent file. Send by COB 12/18/2009.

deployment migration and temporary SSO disruption

...

Should the DNS TTL be lowered, during the time that both the 1.3 and 2.x IdPs are running concurrently?

Alternatives:

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.

...

• (Vetrans Day)
• Work on new login pages (elimination of Stanford WebAuth)
• Work on Apache rebuild for RHEL3 (done)
• (2 day on Athena)

Week of November  16 (3 days available)

• Work on Apache rebuild for RHEL3 (done)
• Install second instance of 1.3 IdP on idp2-dev.mit.edu
• (2 days on Athena)

Week of November 23 (1 day available)

...

• Start Terracotta investigation (delayed)
• (3 days on Athena)

Note: Bob plans to two two days of vacation in December, these are not yet scheduled or accounted for below.

Week of December 7 (0 days)

• (5 days on Athena)

Week of December 14th

• revisit schedule
• meet with Mark to discuss DNS and F5 issues as they relate to transition plan

Week of  December 21 (2 days available?)

...

• Terracotta
• Start testing needs more detailed planning
• This week will consist of testing the revised 1.3 IdP configuration

Week of January 11th

• test the transition of the 1.3 and 2.x IdPs.
• This will require the cooperation of Mark (or NIST) to perform the DNS changes as needed. 
• Send transition issue message to help staff and stake holders

Deploy week of January 25^th

...