Prepare the Integration of edu-ID - Projects - About us · HR Registration Office Alumni Continuing...

© 2017 SWITCH | 1

Petra [email protected], 28.11.2017

Startseite UntertitelPrepare the Integration of edu-ID

Findings from the first Workshop Series

A story about findings:

At the beginning …

© 2017 SWITCH | 3

…nobody want’s to jump as the first one …

• No experience or guidance

• Unknown pitfalls• Waste of resources• ….

© 2017 SWITCH | 4

…but there are some advantages

• More time for detailed planning

• In parallel with IdMredesign project

• Influence product (individual requirements)

• Funding• ….

© 2017 SWITCH | 5

• EPFL (Pierre Mellier)

• FHNW (Michael Hausherr)

• UNIFR (Gérald Collaud)

• UNIGE (Pierre-Yves Burgi)

• UNIL (Alexandre Roy/Christopher Greiner)

• UNISG (Kai Blanke)

• ZHAW (Nisanth Muthukirushnasamy)

First “Jumpers” (just planning!) are

1

Use an analysis method that fits

© 2017 SWITCH | 7

A simple question

How does the university system landscape related to Swiss edu-ID look like?

NOT a simple question !

© 2017 SWITCH | 8

First try – Processes WG• bspslide

?a brick – but no clear view of

similarities & differences

© 2017 SWITCH | 9

✔Second try – Individual Workshops

2

Explain why integration of edu-ID is easy for services

© 2017 SWITCH | 11

Classic model (majority) Extended modelOne affiliation (or role) at a timestudent@UniX

Multiple affiliations (or roles) at a timestudent@UniX,staff@UniY, alumni@UniZ

Example: Moodle

Example:SWITCHdrive

For vast majority of services: no effort at all!(use of classic model – fully compatible with SWITCHaai)

Service administrators: à decide if their services can profit by the extended model à need to understand how edu-ID works

© 2017 SWITCH | 12

HomeOrg: UniAUnique/persistent-IDFirst/last nameDate of birthEmailPhonePostal addressAffiliationstudy branch“local attributes”

Login

SP

“AAI Model”Stud (UniA)

HomeOrg: UniAUnique/persistent-IDFirst/last nameDate of birthEmailPhonePostal addressAffiliationstudy branch“local attributes”

Login

SP

“Classic Model”

privatstud(UniA)

staff(UniB)

Affiliation chooser

SWITCH edu-id

Unique/pers-edu-IDHomeOrg eduid.chNameEmail (user-managed)Home postal address Mobile phoneDate of birthORCIDAffiliation student@UniAstudy branch Email (affil) [email protected] staff@UniBEmail (affil) [email protected] phoneBusiness postal address

Login

SP

“Extended Model”

privatstud(UniA)

staff(UniB)

Optionalaffiliation choice

SWITCH edu-id

WAYF

3

3 is the magic number …

© 2017 SWITCH | 14

1. The least ideal world: “Meta Directory”

Employees HR

StudentsStudentadmin

OthersCont.Educ.,etc.

Business Apps (e.g. finance,

communication)

edu-ID IdM

IT ServicesBusiness Units SWITCH

Management Systems

??“Meta” DB

Others

- role-centric- not persistent- de-centrally managed- less efficient and agile

© 2017 SWITCH | 15

2. The less ideal world: “Provisioning System”

Employees HR




communication)

edu-ID IdM

IT ServicesBusiness Units

Provisioning Engine

SWITCH

Management Systems

“Meta” DB

?

Others

© 2017 SWITCH | 16

3. The ideal world: “Leading System”

Employees HR




communication)

edu-ID IdM

IT ServicesBusiness Units

UniversityIdM

SWITCH

Management Systems

- user-centric- persistent- centrally managed- more efficient and agile

© 2017 SWITCH | 17

• “Meta-Directory” still prevalent today…– Introduced 10-15 years ago– Single most important precondition for AAI

• … but its limitations create growing pains– Not well supporting business application integration– Crisscross processes create high complexity

• Evolving is on the agendaa) Running/procuring a “leading system” (FHNW, EPFL)b) Planning/running a “provisioning engine” (ZHAW, UNIL, UNIFR)c) Advanced plans shelved, (temporarily) accepting deficiencies (UNISG)d) Keeping “Meta-Directory”, central role of Shibboleth IdP (UNIGE)

Situation at Universities –IdM evolving is in favour of edu-ID

© 2017 SWITCH | 18

Meta-Directory

Provisioning System

Leading System

> Decentralised user management

> Basic support to business applications

> Crisscross processes between business applications and leading systems

> Role-scoped user management

> Limited benefit of new SWITCH edu-ID features

> Decentralised user management

> Single point of contact for business applications

> Streamlined processes between business applications and IAM system

> Role-scoped user management

> Limited benefit of new SWITCH edu-ID features

> Centralised core user management

> Single point of contact for business applications

> Streamlined processes between business applications and IAM system

> User-centric user management

> Full benefit of new SWITCH edu-ID features

MetaDirectory

ProvisioningSystem

• Improved agility and support for business applications• Stronger role of the IT department as integration orchestrator

© 2017 SWITCH | 19

Meta-Directory

Provisioning System

3. Leading System

• Adoption scenarios adapted to identity management ripeness• Does not replace individual adaptation and planning efforts

> A1 Adoption Scenario > B1 > C1

> A2 > B2 > C2

1. MetaDirectory

2. ProvisioningSystem

> A3 > B3 > C3

Models are generic but adoption scenarios must be individual

© 2017 SWITCH | 20

Meta-Directory

Provisioning System

Leading System

> 2. de-central pre-linkingmember enrolment with edu-ID login

> 3. central linkingmember enrolment with edu-ID login

> 1. post-linkingduring creationof local account

MetaDirectory

ProvisioningSystem

> post-linkingafter creationof local account(à part of members)

3 ways of edu-ID Linking for NEW members

© 2017 SWITCH | 21

Member un-enrolment

“Meta Directory (synchronous)”

Employee mgt system

Studentmgt system

Cont. educ. mgt system

edu-ID IdM

User data flow

Member enrolment ID

Meta DBFull edu-ID coverage

Member enrolment

Member enrolment

edu-ID IdP

edu-ID Linking(i.e. mail invitation)

affiliation ID

email

ID

offboarding,updates

(by periodical polling)

ID, affiliation

Account

Creation

edu-ID protected web site

onboarding(notification)

© 2017 SWITCH | 22

“Meta Directory”

Employee mgt system

Studentmgt system


edu-ID IdP

edu-ID IdM

Member enrolment

Email, Name, ID

ID, affiliation

Member un-enrolment

Meta DBFull edu-ID coverage

Member enrolment

Member enrolment

User data flow edu-ID protected web site

on-/off-boarding

,updates(notificatio

n)

© 2017 SWITCH | 23

“Leading System”

Employee mgt system

Studentmgt system


Leading IdM

system

edu-ID IdP

edu-ID IdM

Member enrolment(online form with edu-ID Login)

EmailName

ID

Email, Name,ID, …

ID, affiliation

Member un-enrollment


on-/off-boarding

,updates(notificatio

n)

© 2017 SWITCH | 24

Member un-enrolment

“Meta Directory (asynchronous)”

Employee mgt system

Studentmgt system


edu-ID IdM

Member enrolment ID

“Meta” DB

Partial edu-ID coverage

Member enrolment

Member enrolment

edu-ID IdP

edu-ID Linking emailID

ID, affiliation


affiliation ID

onboarding(notification)

offboarding,updates

(by periodical polling)

© 2017 SWITCH | 25

Scenario 1: Involve all Users BEFORE Day Xaai: Uni

aai: Uni

edu-ID

aai: Uni

edu-ID

edu-ID• Uni

Merge linked accounts

à Linked accounts have limited functionality

à Users can’t access to classic SPs as Org-members

Day X

Before Day X:Invite users to create and link edu-ID account

3 ways of edu-ID Linking for CURRENT members

© 2017 SWITCH | 26

Scenario 2: Involve Users AFTER Day Xaai: Uni

aai: Uni

edu-ID

edu-ID• Uni


After Day X:Invite users to create and link edu-ID account

aai: Uni

edu-ID

internal

Users lose federation account

Day X

à Users can’t access (external) resources before they link

© 2017 SWITCH | 27

Scenario 3: Create edu-ID for Usersaai: Uni

edu-ID• Uni


aai: Uni

edu-IDCreate edu-ID accounts Day X

aai: Uni

edu-ID

edu-ID 2

edu-ID

à Users ev. get duplicates

User-centric might be

better

4

IdP ≠ IdP

© 2017 SWITCH | 29

- one of many- standard configuration

IdPC

IdPB

IdP D

IdPE

AAI IdP

IdPA

University X

AAI IdP

IdPA

IdPB

- important for accessingexternal resources

IdPC

University Y

AAIIdP

IdPA

- central element also for accessing internal resources

- individual configuration

University Z

5

Central IT does the job

© 2017 SWITCH | 31

Stakeholders (Implementation)External Parties

Students

Teachers

Researchers

Central IT

Service Providers

Career Services

HR

Registration Office

Alumni

Continuing Education

Certification Office

Security Office

Legal OfficeLibrary

Support

Communication Dept.

Administration

Facility Management

Headhunters

Job Markets

Companies(HR)

Content (Platform) Providers

Publishers

Social Networks

Additionally involved

Management

Leading “actors”

© 2017 SWITCH | 32

Stakeholders (Planning Projects)External Parties

Students

Teachers

Researchers

Central IT

Service Providers

Career Services

HR

Registration Office

Alumni

Continuing Education

Certification Office

Security Office

Legal OfficeLibrary

Support

Communication Dept.

Administration

Facility Management

Headhunters

Job Markets

Companies(HR)

Content (Platform) Providers

Publishers

Social Networks

Additionally involved

Management

Leading “actors”

6

Effort estimation realistic but planning slower &

according to individual pace

© 2017 SWITCH | 34

Effort examples (estimation ca. 1 - 1.5 PM)FHNW:• 4 Workshops, 2 days per person, 5 people = 10 days 10 days

- Big part of the groundwork was done in the IAM project- Pilot projects handled outside of planning project

UNIFR:• Preparatory Work (AAI Admin) = 1 day• 3 Workshops, ¾ day per person, 5 people = 4 days• 3 technical and 2 planning discussions = 2 day 9 days

- Objectives set upfront & internal project in parallelZHAW:• Preparation for workshops = 1 day • Analysis of impact = 3 days• 2 workshops, 6 people & inidividual meetings = 7 days 11 days

- Understanding of IAM processes within internal project

© 2017 SWITCH | 35

Planning@Universities: Next Steps

Most advanced• ZHAW: Present scenario proposition to management

Advanced• FHNW: Elaborate details for Single Sign On with Kerberos• UNIL: Elaborate detailed planning• UNIFR: Decision about scenario, elaborate detailed planning

On the way• EPFL: Elaborate detailed planning (waiting for legal opinion about attribute caching)• UNISG: Scenario clarified. Define new project leader at UNISG• UNIGE: Evaluate alternatives to Attribute Provider (keep local IdP)

7

No recipe but “jumping plan” for integration

© 2017 SWITCH | 37

“Jumping plan” checklist (tbd)

◻ 1. Configuration of all services okay◻ 2. All local attributes entered in RR Alternative solution: ….◻ 3. Onboarding (edu-ID Linking) scenario for new members (all groups) in place Details: …◻ 4. Onboarding (edu-ID Linking) scenario for current members in place Details: …◻ 5. Offboarding interface implemented & tested Details: …◻ 6. Help Desk prepared Measures: Training, FAQs, …◻ 7. Communication with users defined

Details: …◻ 8. All measures before, during and after Day X visualized in a flow diagram…....

© 2017 SWITCH | 38

First “jumpers” integrating SWITCH edu-ID2017: SWITCH

2018: UNILU, PHZUG

2018/19: UNIL, ZHAW

2019: FHNW, UNIFR, UNISG, …

(to be confirmed)

See also flyer: https://swit.ch/flyer

© 2017 SWITCH | 40

Working for a better digital world

… and how we plan to integrate the SWITCH edu-IDIdentity management redesign @ FHNW

28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 2

Agenda

Why?

Why, really?

Why now?

How we want it to work …

The project at FHNW (history and outlook)

The IdM System: Key functional areas


Why?

Current solution was built around 10 years ago (time of foundation of FHNW) and has reached its limits:

− Script-based approach

− Manual interventions necessary

− Difficult to maintain

− Lacking transparency and slow

− Every additional case makes it more complex

− Permissions for every system and application are handled differently(concepts, naming, processes, tools, etc.)


Why, really?

− Access management for resources and applications is based on thousands of technical roles and permissions (e.g. Active Directory groups) with cryptic names that are incomprehensible to end users.

− Together with the lack of transparency about the process status and the complexity of the system with extensions and special cases added over the years, this leads to a high number of support requests. Many of them are difficult to analyze, time-consuming and therefore expensive.

− Timely, agile development, adaptation and expansion is not possible because of limitations and complexity of its technical basis.

− The SWITCH edu-ID can only be partially integrated because everything is currently tied to an Active Directory account. Therefore we foresee that we can only benefit from new features and optimization possibilities in a limited way.


Why now?

− Improved identity management has been identified as an important prerequisite for further projects in the area of standardization, automation and self-service. critical path!

− Coordination and parallel conceptual work between FHNW IdM redesign and SWITCH edu-ID integration planning is expected to be very useful, because both projects can learn and benefit from each other; work on both sides can be aligned.


How we want it to work …

Same high-level process for many use cases of the SWITCH edu-ID at FHNW:

1) On-boarding (creating a relation/affiliation with the organization)

2) «Identity» creation within the identity management system (IdM) andProvisioning of necessary SWITCH edu-ID attributes («Affiliation», others)

3) Access to FHNW resources

… and a few words about the data exchange between FHNW and SWITCH


Step 1: On-boarding

A relation/affiliation with the FHNW is created through an «on-boarding» application, e.g.

− ONLA (Online Application for Bachelor/Master studies)

− EVER (Online Registration for further education programs and courses)

− Groups Inside FHNW (SharePoint collaboration platform, for external partners)

Process can be initialized by the identity owner him/herself (ONLA, EVER) or when a person within the FHNW (e.g. Project Manager) invites an external partner.

Technical aspects: Service Providers (SPs) for on-boarding applications need the edu-ID GUID attribute in order to «recognize» the edu-ID identity and start the following process steps. Applications with «Invitation» functionality can use the existing API to check for an existing edu-ID.


Step 2: «Identity» creation and attribute provisioning

− Data from the on-boarding applications is passed on to the IdM system

− The IdM system creates an «Identity» with a generic «affiliation role» and probably other attributes/roles based on the data received

− Provisioning of necessary SWITCH edu-ID attributes («Affiliation», others)

− Attribute information is available directly at the FHNW attribute provider

− IdM system triggers a notification to the IdM provisioning service of the edu-ID regarding the new affiliation and any other associated attributes


Step 3: Access to FHNW resources

In general, 3 different cases can be distinguished when accessing protected FHNW resources using a SWITCH edu-ID:

a) No FHNW-Affiliation available Access denied (Redirect to on-boarding application where useful)

b) Access possible based on available affiliation attributes (including details) Allow access directly

c) Access only possible with specific permissions Access request can be made through the web-based IdM portal

which is accessible as mentioned above in b)

Technical aspects: − Because of a) the provisioning of a new edu-ID affiliation at SWITCH must be immediate− The «shared attribute» functionality can be used for a similar result already now


Data exchange between SWITCH and FHNW

− Affiliation attributes:

− From FHNW (Attribute Provider) to SWITCH (Attribute Aggregator),

− SAML2 Attribute Query

− Notifications regarding new, changed and removed attributes:

− Bidirectional between FHNW (IdM System) and SWITCH (IdM Provisioning Service)

− Based on preliminary research we see SCIM (System for Cross-Domain Identity Management, defines schema and protocol) as a suitable approach. A good number of IdM systems support this through some level of customizing.

− Should be generally implemented as machine-to-machine interfaces. If manual steps are necessary, they should be implemented as a workflow within the IdM system.


How we want it to work … illustrated

1) On-boarding (creating a relation/affiliation with the organization)

2) «Identity» creation within the identity management system (IdM) andProvisioning of necessary SWITCH edu-ID attributes («Affiliation», others)

3) Access to FHNW resources

ONLA

EVERGroups Inside

IdM System


The project at FHNW (history and outlook)

− Project application in June 2016

− «As Is» analysis and rough concept

− Project order in November 2016

− Further concept work,Public tender (preparation of documents, offer evaluation, decision) andSWITCH edu-ID migration workshops

− Proof of concept, Nov. / Dec. 2017

− Project phase «Baseline», Go-Live planned in Mai 2018

− Further development (agile) and roll-out of FHNW role model in all departments

− Migration from AAI to edu-ID possibly in Q1/2019


The IdM System: Key functional areas

− Identity life cycle

− Entitlement management

− Access requests

− Workflow

− Policy and role management

− Access certification (sometimes called «attestation»)

− Fulfillment

− Password management

− Auditing

− Reporting and analyticsSource: Gartner, Definition Identity Governance and Administration, ID G00310264


Questions?

Contact:− Michael Hausherr, Enterprise Architect

T: +41 56 202 71 56, E: [email protected]− Markus Obrist, Enterprise Architect

T: +41 56 202 74 78, E: [email protected]

mailto:[email protected]

mailto:[email protected]

© 2017 SWITCH | 1

Andres [email protected] 28.11.2017

Startseite UntertitelMFA/2FAWho is actually issuing the second factor?

© 2017 SWITCH | 2

What is Two-Factor-Authentication?

© 2017 SWITCH | 3

Translation to e-world

© 2017 SWITCH | 4

Translation to e-world

© 2017 SWITCH | 5

What factor?• Password• HOTP• TOTP• Paper token• Questionnaire token• OTP sent by E-Mail• OTP sent by SMS• PIN• Certificates (X.509)• SSH PublicKey• TiQR• U2F (FIDO)• Yubikey• Fingerprint• MobileID• Background noise• …

Source:• Biomemory• Finger, Eye• Sheet of paper• Specific device• Mobile phone• Smartphone• Browser• Computer with Harddisk

© 2017 SWITCH | 6

What factor?• Password• HOTP• TOTP• Paper token• Questionnaire token (?)• OTP sent by E-Mail (?)• OTP sent by SMS (?)• PIN (?)• Certificates (X.509)• SSH PublicKey• TiQR• U2F (FIDO)• Yubikey• Fingerprint• MobileID• Background noise• …

Source:• Biomemory• Finger, Eye• Sheet of paper• Specific device• Mobile phone• Smartphone• Browser• Computer with Harddisk

© 2017 SWITCH | 7

Practical considerations

• Hardware tokens imply (more) support effort• Out-of-band internet connection is not

always given• Use of private smartphone may find

reluctance (separation between work/personal life)

© 2017 SWITCH | 8

Who is actually needing protection?

A: The user:E.g. when using a bank account application

B: The service:E.g. when the user is an administrator of a tax office application.

© 2017 SWITCH | 9

Bank account

© 2017 SWITCH | 10

Tax application

© 2017 SWITCH | 11

Sum up• Use Case 1: Protect the end user. Then all the processes

around can simply be imposed on the end user, because he’s the one who profits, and he’s the one responsible for his own protection. Then the application/authentication may offer 2FA.

• Use Case 2: Protect the application. Then it’s the responsibility of the application’s owner to define appropriate processes for key issuance, and all the other processes as well. Then the application/authentication must enforce 2FA.

© 2017 SWITCH | 12

Weak points?

© 2017 SWITCH | 14

Implementation ideas

• Let the user set up a second factor.

• Then let the organization approve it.

✔

✔

© 2017 SWITCH | 15

Wrap up

Q: Who should control the second factor?

A: It’s the party that needs protection!

Q: What is the missing piece between a ”self-declared” 2nd factor and a 2nd factor issued by an organization?

A: It’s the validation process done by the organization.

© 2017 SWITCH | 16

https://www.schneier.com/blog/archives/2016/08/nist_is_no_long.html

https://www.srf.ch/news/schweiz/e-banking-wer-kein-smartphone-hat-muss-bei-der-zkb-bezahlen

https://meetings.internet2.edu/2017-technology-exchange/detail/10004829/

https://futurae.com/

Links

© 2017 SWITCH | 1

Rolf [email protected], Lugano, 27 November 2017

Startseite Untertitel

How an OrganizationIntegrates edu-IDUsing the example of SWITCH

The organization SWITCHadopts edu-ID

The User’s Perspective

Communication to Users

x – 6 months“Get an edu-ID and link it to your AAI – account”

x – 10 days“SWITCH will integrate edu-ID. You will see a new login window.• Use your email address as user name• Use your SWITCHdrive password or

set a new one.“

User Experience before Day X

User Experience after Day X

Using a Service as Private User

The Perspective of the Service Providers

Communication to Service Providers

x – 10 days“SWITCH will integrate edu-ID. Users will see another login window. Technically, nothing changes for the SP„

Woah! We need more time

for testing!

Our metadata is hardwired!

The Perspective of the Organization

© 2017 SWITCH | 15

edu-ID IdP

Entity-ID: edu-ID.ch

Entity-ID: uni-x-backchannel.ch

Setup with an Integrated Organization

aai: Uni-X

edu-ID

IntegratedLinked

edu-ID• Uni-X

edu-ID Login

edu-ID IdP

Uni-XIdP

WAYF

Affiliation chooser

Entity-ID: uni-x.ch

Entity-ID: edu-ID.ch

Entity-ID: uni-x.ch

Old Uni-XIdP

© 2017 SWITCH | 17

SWITCH IdM before Day X

Employee mgt systemregistration (web-form)

edu-IDLDAPDirectory

IdP(Shibb)

id Name Email Addr …

send registration form to employee (paper)

Fill in registration form and send it back

Fill in internal web form

Send data to directory

Activate account on first working day

HR new employee

© 2017 SWITCH | 18

SWITCH IdM after Day X


edu-IDLDAPDirectory

IdP(Shibb)

id Name Email Addr …

send registration form to employee (paper)

Fill in registration form and send it back

Fill in internal web form

Send data to directory

Activate account on first working day

HR new employeeLink edu-ID

eduID-Ident

AP

edu-ID

Create affiliation

Link edu-ID, sends Identifier by email

with edu-ID instruction

© 2017 SWITCH | 22

Account Linking Page (Draft)my.unifr.ch SWITCH edu-ID

edu-ID login create edu-IDhttps://eduid.ch/linkacc?code=123XYZ&ret=my.unifr.ch/linkacc

link edu-ID login

link

create

edu-ID linked

https://my.unifr.ch/linkacc?code=123XYZ&id=f7b83c42-9f3d-45de-8146-1e00e15938a9

Conclusions

© 2017 SWITCH | 24

• Involved parties at the Organization• Human resources• IdM/Account management• Support• Communication

• Everything went smoothly

Adopting the edu-ID at SWITCH

1d3-4d1d1d

© 2017 SWITCH | 25

Individual Roadmaps

Leading System Meta-Directoryw. pre-linking Meta-Directory

w. post-linking

Users link before X Users link afterX Account provisioning

Account linking

Onboarding

AP-Interface Attribute push Attribute pull

© 2017 SWITCH | 26

Adopting the edu-ID at Organizational Level

Users Service Providers

Organizational Identity Management

• Get an edu-ID• Link your

organi-zationalID to your edu-ID

• (no changes) • Provide mechanism to link edu-ID of new users to organizational ID

• Extend directory with edu-ID identifier

• Replace IdP by attribute provider

• Inform edu-ID about new members (REST API call)

Prepare the Integration of edu-ID - Projects - About us · HR Registration Office Alumni Continuing...

Documents

Transcript of Prepare the Integration of edu-ID - Projects - About us · HR Registration Office Alumni Continuing...