eAuthentication in Higher Education

Tim Bornholtz

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

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

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