1. 1 eAuthentication in Higher Education Tim Bornholtz Session #47

2. 2 What is the problem? We all have different passwords to many different systems. We should be able to log in once and use those credentials as we move from site to site. Must be able to securely pass credentials without compromising passwords.

3. 3 Transitive Property of Equality If a = b and b = c, then a = c Note: This is a property of equality and inequalities. One must be cautious, however, when attempting to develop arguments using the transitive property in other settings.

4. 4 Mathematics and Trust A trusts B and B trusts C. Does this mean that A will trust C? These trust relationships can only go so far. We probably would not trust a friend of a friend of a friend of a friend. There are not indefinite levels of trust. The boundaries of your trust make up the Federation.

5. 5 Federations A Federation is a group of organizations that have agreed to trust each other. All members of the Federation trust all other members within the Federation. Separate agreements with each and every member not necessary.

6. 6 Rules of a Federation Members agree to abide by rules of the Federation. Each Federation has some sort of “steering committee” that decides on the rules: –Legal rules – who can participate and what can they do within the Federation. –Technical rules – technical infrastructure and specifications necessary to communicate with other Federation members.

7. 7 So what is eAuthentication? eAuthentication is a Federation of US government agencies and private sector organizations. GSA is coordinating the Federation –Determined the legal policies required for joining the network. –Specified the technical requirements to participate.

8. 8 How do Federations work? Security Assertion Markup Language (SAML). Security authentication statements are passed as XML from one provider to the next. Passwords are never sent across the wire. Assertions are signed with XML signatures and verified as valid participants within the Federation.

9. 9 Some Current Federations Shibboleth based federations (InCommon) ‏ Federal Government (eAuthentication) ‏ Meteor

10. 10 Shibboleth Shibboleth is an Open Source Web Single Sign On system Currently supports SAML 1.0 and 1.1 Shibboleth 2.0 in Open Beta –Supports SAML 2.0 –Interoperable with many other SAML 2.0 compliant products

11. 11 InCommon A federation of higher education and research institutions in the U.S. Uses Shibboleth as its federating software. Membership continues to grow –Currently over 60 participants. –Serving over 1.3 million end users.

12. 12 InCommon and eAuthentication December 2006 InCommon demonstrated federated access to National Institutes of Health (NIH), by two campuses GSA has reiterated that interfederated interoperability with InCommon is a high priority

13. 13 Other Shibboleth Based Federations FEIDE – Norway –Educational sector in Norway. HAKA Federation – Finland –Identity federation of Finnish universities, polytechnics and research institutions SDSS – United Kingdom –Federation for managing access to UK academic online resources SWITCH – Switzerland –Eleven universities - more than 140,000 users –More than 80 resources - primarily in the field of e- learning

14. 14 Federal Student Aid Shibboleth as a relying product was chosen by Federal Student Aid as the primary solution for E-Authentication. eCampus Based will be the first application to be E-Authentication enabled. Integrate E-Auth Solution (Shibboleth) into Federal Student Aid Security Architecture. Utilize Federal Student Aid Security Architecture TAM LDAP.

15. 15 Federal Student Aid Status Received official sign off and acceptance testing report from GSA. Awaiting hardware at Perot VDC. Inter-System testing in progress. Go Live date scheduled for December 2007.

16. 16 Meteor Network Meteor is an Open Source application that aggregates student financial aid. information from multiple sources Meteor 3.3 available for testing September 15. Production availability December 2007. –Technical enhancements to increase security and auditing. –Usability enhancements based on extensive customer feedback.

17. 17 Meteor Technical Infrastructure Uses SAML assertions to convey authentication information. Assertion is signed with XML signatures. Each request is also signed with XML signatures. Uses central Index Providers to determine optimal locations of data. Data Providers access real-time backend systems for up to date information.

18. 18 Implementation Roadmap How to join a federation. Define the business problem. –Make sure you understand the business problem you are solving. Get started with legal process as soon as possible. –May take up to 18 months for internal legal approval. Technology is not complicated.

19. 19 Federation Concerns Policy determination and enforcement –Who makes the rules? How are they modified? Provider eligibility –What is the scope of the federation? Security and privacy –Technologies used. –Appropriate policies in place. Removal from the network –What are the legal and political ramifications?

20. 20 Lessons Learned The policy work is much harder than the technical work. The legal staff at every member will need to review the policies. All members will need to be educated: –Why federations work –Why they are secure

21. 21 Summary I appreciate your feedback and comments. I can be reached at: Name:Tim Bornholtz Phone: 540-446-8404 Email: tim@bornholtz.com Web: http://www.bornholtz.com