...

Idp1 and idp2 are running on RHEL3 physical machines. NIST has also provided idp2-dev, which is also a RHEL3 machine. Bob has been using foonalagoona which is provided by OPS/AMIT. This is not a RHEL3 machine. To complete the transition new RHEL5 VMs will be requested from NIST:. In addition to the OS upgrade, several other components will be upgraded as well. For example, we have been using Apache 2.0 and will be going to 2.2. We've been using Tomcat 5.5 and will be going to 6. We have been using Java 5 and will be going to 6.
 

1. 1. 1 dev machine
   2. 2 staging machines
   3. 2 production machines
   4. Configuration:
      1. minimum RAM 2GB, suggest 4GB we're requesting 4GB.
      2. at least 10Gb disk, 7200 RPM
      3. Switch Federation recommends on a physical machine the CPU should 4 cores, each running at 2GHz. It has been noted that IdPs tend to be CPU bound, not disk io or network bandwidth intensive.

...

1. Authentication mechanisms:
   1. Username/password (done) urnpassword 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 2 weeks 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.

Cease to support artifact query

We will be removing the artifact query support from the MIT metadata.

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.
4. Need to determine when this change will be made.

Migrate from SP attribute query to IdP attribute push.

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.
 
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. We will be removing the artifact query support from the MIT metadata. Need to determine when this change will be made.
 
(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.  

Pre-idp 2.1 deployment changes to the existing 1.3 IdPs

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.
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 new IdP instancesthe modified IdPs , with the new endpoints running 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.

...

We should strongly consider ignoring this recommendation and migrating to the URL form of entityID within the InCommon metadata.

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

deployment migration and temporary SSO disruption

We’re thinking about adding the new IdPs to the existing idp.mit.edu DNS round robin. It should then be possible to remove the 1.3 IdPs from the DNS pool, without shutting them off. If necessary, they can then quickly be added back to the DNS pool, and the new IdPs can be withdrawn. We need to coordinate with Mark what the DNS TTL should be, and what procedures should be used to get a DNS change to happen, in a timely manner.

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.

...

All of the work to be done to migrate the core IdPs is also applicable to the TouchstoneNetwork IdPs, with the exception to the work required to eliminate Stanford WebAuth from the core IdPs. We expect that once the core IdPs have been transitioned, it will simply be a matter of applying nearly the same configurations to the new CAMS IdP machines, and testing them. I expect that However, there is other work that is required. Today, CAMS uses a Tomcat realm for authentication. For the transition to Shibboleth 2.x, a new JAAS Tomcat module that interacts with the CAMS MySQL database needs to be written to support the username-password mechanism. The Internet2 provider JAAS Kerberos handler is not applicable in the CAMS situation.

In order to speed up the work we plan to drop the support for OpenID, at least temporarily. In the last several quarters we have seen only one user each quarter use this feature. It appears that in all cases it has been IS&T employees testing the feature. We do not believe that any customers are currently using the feature. We feel that migrating this feature to the new generation of IdPs will require several weeks of effort and this can be done post transition.

By dropping the OpenID support, temporarily, we believe this phase of the transition can be done in approximately two approximately four weeks of time.

Phase Three: improve SP registration

...

• Request new VMs from NIST
• Remove the artifact query support from the MIT metadata.
• Schedule CAMS restart with new Moira WS settings
• Work on new login pages (elimination of Stanford WebAuth)
• (2 days on Athena)

Week of November 2^nd (4 3 days available)

• Work on new login pages (elimination of Stanford WebAuth)
• (1 day on Athena)
• (Bob will take one day of vacation)

Week of November  9 (3 2 days available)

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

...

• Start Terracotta investigation
• (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)

...