Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
© 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
StudentsStudentadmin
OthersCont.Educ.,etc.
Business Apps (e.g. finance,
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
StudentsStudentadmin
OthersCont.Educ.,etc.
Business Apps (e.g. finance,
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
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
Cont. educ. mgt 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
Cont. educ. mgt 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
User data flow edu-ID protected web site
on-/off-boarding
,updates(notificatio
n)
© 2017 SWITCH | 24
Member un-enrolment
“Meta Directory (asynchronous)”
Employee mgt system
Studentmgt system
Cont. educ. mgt 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
User data flow edu-ID protected web site
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
Merge linked accounts
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
Merge linked accounts
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 | 39 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
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 3
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.)
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 4
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.
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 5
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.
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 6
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
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 7
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.
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 8
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
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 9
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
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 10
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.
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 11
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
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 12
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
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 13
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
28.11.2017Corporate IT, FHNW / Presentation for ICT Focus 2017 14
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]
© 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 | 13
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 | 17
Working for a better digital world
© 2017 SWITCH | 1
Rolf [email protected], Lugano, 27 November 2017
Startseite Untertitel
How an OrganizationIntegrates edu-IDUsing the example of SWITCH
© 2017 SWITCH | 2
From Full Mesh to Hub’n’Spoke
X
The organization SWITCHadopts edu-ID
© 2017 SWITCH | 4
identity management
users
organisations services
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
© 2017 SWITCH | 11
Affiliation Chooser (Draft)
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 | 16
Adoption Approaches
Leading System
Meta-Directoryw. pre-linking
Meta-Directoryw. post-linking
© 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
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 employeeLink edu-ID
eduID-Ident
AP
edu-ID
Create affiliation
Link edu-ID, sends Identifier by email
with edu-ID instruction
© 2017 SWITCH | 19
Registration of a new Member
Employee mgt systemregistration (web-form)
LDAPDirectory
Link edu-ID
© 2017 SWITCH | 20
Employee mgt systemregistration (web-form)
LDAPDirectory
Link edu-ID
© 2017 SWITCH | 21
Employee mgt systemregistration (web-form)
LDAPDirectory
Link edu-ID
© 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)
© 2017 SWITCH | 27
Working for a better digital world