How can different campuses inter-operate? From ora et labora to - PowerPoint PPT Presentation

How can different campuses inter-operate? From ora et labora to collaborate and federate EuroCAMP, Ljubljana, 2006-04-03 Ingrid Melve, FEIDE manager

From S S O to a federated solution  Campus Identity Management  Collaborations  Applications 2  Case: FEIDE  Federating for applications

Application types  Web: apache, IIS , python, php, .NET  Web services: Java  Legacy applications: 3 i.e. S AP, ePhorte, Agresso  Network access: wireless (802.1X), radius  Proxies: web, Citrix  Agents acting on behalf of the user: web services or legacy/ special applications

Important applications  S hared apps  Local apps  self service  e-learning interfaces  portals 4  library services  wireless access  administrative  Local apps with services outside users  reporting  All of the above systems  Project  National apps workspace  Government  security portal

Applications need to change  Move login out of the service itself  Application does not see password  Need to add module or filter in 5 application  How to integrate with FEIDE  Moria2: operational until spring 2007  Liberty Alliance standards chosen as future integration path  Conformance testing ensures multi- vendor support  S un Access Manager in demo June 2006

Norwegian universities and university colleges and how to ICT  4 big, 6 medium,  Multi-vendor 28 small environment institutions  S hare 6  Collaboration administrative normal and useful applications  NREN has strong  S tudent registry campus presence  Payroll system  CIMS user groups  Financial system  Novell  Electronic invoice  Microsoft  Archive system  Cerebrum

FEIDE – Federated Electronic Identity for Norwegian Education  FEIDE is a non-commercial identity management federation for people in education  FEIDE is technology and plattform agnostic 7  FEIDE offers guidelines and policy for campus identity management  FEIDE-names are valid for all education services, and may be used internally, for community services and with educational related services

A solution for whom?  Higher ed: 230000 person, 53 institutions  (Lower ed: 780000) 8  Total: 20% of population  Tradition of sharing work  Dugnad  Many shared services  Common software  Application S ervice Providers  Common interfaces

FEIDE – the players End user person with FEIDE-name 9 Home organization - IdP university or school with end user affiliation S ervice Provider S ervices and applications for end users

FEIDE for Norwegian education  Operational campus (start 2003)  Universities: 2003 - early 2006  University Colleges: 2004 - 2006 10  Lower education: phasing in from fall 2006  Operational service providers  S hared services in higher ed: 2003 - 2006  Community web services in lower education: 2006 – 2007  Local university services: 2003 – 200X

FEIDE – identity management for education Identity management consists of:  Information model  Login service 11  Chain of trust  Policy issues  Collaboration between educational institutions, service providers and vendors

FEIDE information model  Identity providers (=campus)  Authoritative data flows to LDAP- 12 directory  Information on standard format  eduPerson, eduOrg  norEduPerson, norEduOrg, norEduOrgUnit  S tandardized import/ export  Provisioning  S ervice Provider integration  Requirements for campus identity management

Campus Identity Management 13  Authoritative data sources  BAS (CIMS ) is hub in information flow  All updates and changes flows through BAS  CIMS is a neccessary component

Campus Identity Provider benefits 14  Authoritative quality and control of information flow for all affiliated users  Enhanced user management simplifies and automates  Federated login provides access to services

CleanIT, the BAS /CIMS process  Identify key data  Identify who is reponsible for  Initial data 15  Data updates  Data removal  Organizational process  Move data maintenance out of the IT department  Enable Human Resource and S tudent Management staff to do their j obs better

What is Campus Identity Management S ystems (CIMS )?  Routines and policy for data updates  Data quality, well-defined requirements  Quality assurance (identity) 16  Not really an «application»  Technical solutions:  Cerebrum  Novell  S tover's Microsoft-based  Incoming: Oracle and IBM  (In-house ad-hoc solutions are operational)

Campus Identity Management S ystems  S everal systems are operational, pick one for your campus  Integration with local systems decide 17 which one to chose, dialogue with vendor  Not cost-effective to have many  Federating across different systems is relatively painless  Interfaces are important in bottom-up design  Collaboration, work with vendors

Campus status Status i innføringsprosessen Antall Organisasjon Type BAS FEIDE -navn Studenter Ansatte Andre FEIDE NTNU BDB 22000 Universitetet i Bergen SEBRA 20000 Universitetet i Oslo Cerebrum 36000 Universitetet i Stavanger ? 7300 2007 Universitetet i Tromsø Cerebrum 6100 2006 UMB Egenutv. 2800 2006 Høgskolen i Agder Cerebrum 8000 Høgskolen i Akershus ? 3500 2006 Høgskolen i Bergen Microsoft 6000 2006 18 Høgskolen i Bodø Microsoft 4700 2006 Høgskolen i Buskerud Novell 2800 2006? Høgskolen i Finnmark Novell 2100 Høgskolen i Gjøvik Novell (?) 2100 2006? Høgskolen i Harstad ? 1600 Høgskolen i Hedmark Novell 5600 Høgskolen i Lillehammer Novell 3700 Høgskolen i Molde Microsoft 1600 Høgskolen i Narvik Microsoft 1200 April 2006 Høgskolen i Nesna ? 1000 Høgskolen i Nord-Trøndelag Microsoft 5000 2006 Høgskolen i Oslo egenutviklet 11200 Høgskolen i Sogn og Fjordane Novell 3000 2006 Høgskolen Stord/Haugesund Microsoft 2500 2006/2007 Høgskolen i Sør-Trøndelag Cerebrum 8100 April 2006 Høgskolen i Telemark Novell 6600 2006 Høgskolen i Vestfold Novell 3400 2006 Høgskolen i Volda Novell 4000 April 2006 Høgskolen i Østfold Cerebrum 4200 2006 Høgskolen i Ålesund Microsoft 1800 Samisk Høgskole ? 180 Norges Handelshøgskole Microsoft 2600 2006 190680

Future directions, campus IdM  Responsibility placed outside IT department  Consolidating BAS for user 19 management  Technical solutions  Policy and regulations  Giving access to someone I do not control?  Interfaces  XML definitions for import/ export  LDAP based on eduPerson/ noredu*  Available software is improving

Proposed Educational ID engine  Purpose of an publicly available ID engine  Unique user name for the entire 20 educational lifecycle  Easy integration for school owners  Quality control in CIMS  Report to be published in April 2006  Discussion spring/ summer 2006  Expected to be operational late 2006

Provisioning  Campus Identity  S tandardization Management  S haring schema S ystem (CIMS )  Exploring issues 21 import and export  Formal  CIMS is core collaboration  Groups work  Universities  Roles  Vendors  Bulk and/ or event  FEIDE driven data  Education transfer  Various operational solutions

CIMS long term work  Existing solutions will live until 2008  Work is starting on specification of integration with shared/ common 22 applications, provisioning is important  FS , Frida/ Forskdok, Agresso, S AP, HR, eBusiness S uite, ePhorte, BIBS YS  Collaboration on CIMS specification  Look at available systems, development of Cerebrum or development of new system  Common/ shared solution, modular architecture

S haring and Federating Identities  National Identity  FEIDE-name Number  eduPerson  Basis for ID in CIMS PrincipalName 23  Federated ID  Required for some (as in Liberty Alliance) services  Used by  One per user per government service provider  norEduPersonNIN  Controled by Identity Provider  eduPersonTargetedI D

Why federate?  Users and home organizations and service providers 24 need to exchange information  Trust establishment  Information exchange  Policy  Technology

FEIDE federates education Federations:  authenticate 25  enforce information flow policy  privacy control  security  trust establishment

FEIDE – trust chain  FEIDE regulates service providers and home 26 organizations  Formal contractual agreements  Transitive trust from end user to service provider via identity provider

FEIDE login 1)User tries to access service 2)S ervice transfer user to 27 FEIDE login 3)Authentication is done at campus 4)Authentication is confirmed with the service, possibly with attribute release

Federating FEIDE, next try  Federating with  federations  portals 28  local login servers  S tandards  S AML 2.0  S AML 1.1 +extensions  ID-FF 1.2 ?