Session #47

eAuthentication in Higher Education
Tim Bornholtz

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.
2

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.

3

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.

4

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.

5

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.

6

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.

7

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.

8

Some Current Federations
• Shibboleth based federations (InCommon) • Federal Government (eAuthentication) • Meteor

9

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

10

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.

11

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

12

Other Shibboleth Based Federations
• FEIDE – Norway • SDSS – United Kingdom

– Educational sector in Norway.
• HAKA Federation – Finland

– Identity federation of Finnish universities, polytechnics and research institutions

– 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 elearning
13

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.

14

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.
15

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.

16

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.

17

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.
18

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?

19

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
20

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

21