eAuthentication in Higher Education

1. Tim Bornholtz eAuthentication in Higher Education Session #47

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. 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. 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. 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. 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. 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. 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. Some Current Federations • Shibboleth based federations (InCommon)‏ • Federal Government (eAuthentication)‏ • Meteor

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. 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. 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. 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 Other Shibboleth Based Federations • FEIDE – Norway • Educational sector in Norway. • HAKA Federation – Finland • Identity federation of Finnish universities, polytechnics and research institutions

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. 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. 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. 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. 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. 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. 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. Summary • I appreciate your feedback and comments. • I can be reached at:Name: Tim BornholtzPhone: 540-446-8404Email: tim@bornholtz.comWeb: http://www.bornholtz.com