Date post: | 02-Aug-2015 |
Category: |
Education |
Upload: | richard-tong |
View: | 101 times |
Download: | 1 times |
SIF Identification
Management 2.7/3.1 Profile
Usage Guide
Hattie Leary [email protected]
Richard Tong [email protected]
Vince Paredes [email protected]
Linda Marshall [email protected]
The How-to Guide of IDM Profile
The background and profile introduction - Review of
IDM101 (10 minutes)
IDM workflow and use cases explained (10-15 minutes)
Best practice discussions (10 minutes)
The real-world case studies (20-30 minutes)
Background for SIF IDM
Profile
Why do we need SIF Identity Management Profile?
User ID and password are needed for all kinds of web
applications in education. SIF Enabled Educational
Infrastructure needs to provide mechanism to seamless
authenticate end users and grant authorization request.
User ID and password from mobile clients into SIF Enabled
Educational Infrastructure API and/or hosted applications
need to be supported.
APIs, Desktop or backend applications and Custom Apps (such
as data ingestion engine, sync engine, ESB, Data Warehouse,
administrative applications, collaboration tools, custom Apps,
etc.) need to identify themselves and pass credentials from
their end users for participating in the overall SIF Enabled
Educational Infrastructure community.
Where is identity needed?
Benefits of Identity Integration
(Single Sign-On or Same Sign-On)
Reduced Administrative Costs
All user authentication information resides in SEA/LEA, which reduces the need to maintain, monitor and potentially synchronized multiple stores.
Reduces password-related user support requests.
Increased ease of use / adoption
Each user only has a single username and password which grants them seamless access to all of their current resources and SIF Enabled Educational Infrastructure resources.
Single Sign-On also saves users time, since each individual sign-on process can take 5 to 20 seconds to complete.
Enhanced Security
Password policies established for SEA/LEA network will also be in effect for SIF Enabled Educational Infrastructure.
Automatic provisioning and deprovisioning of users prevents unwarranted access.
Sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data.
Beyond SSO
Before SSO can happen, how are Identifications in both
IDP and SP provisioned and linked to ensure consistency?
How are authorization and entitlement information
exchanged in either SSO enabled environment or even
Same-sign-on environments?
We also need cross-app authorization,
Requirement for the SIF IDM
Profile Solution
Provide a common logical data model for all participant applications
Provide a standard least-common-denominator data schema for compliant applications to exchange IDM related data
Expand on the current SIF 2.5 profiles
Align with CEDS (We already embed the new profile in CEDS 3.0 by working with the CEDS team)
Provide a best practice workflow framework to support the common use cases
Provide a migration path and real-world case studies to ease the adoption and transition
Scope of SIF IDM Use Cases
Provisioning of Identity and Access across multiple
connected systems
Provisioning of identity in a directory service provider
Provisioning or de-provisioning of identity in an existing
system
on-demand (personal event driven)
Batch (at BOY, EOY, MOY, etc.)
Provisioning of identity and profile in a new system
Single-Sign-On among multiple education systems
Review of IDM Logical Model Session 101
From 2.7 to 3.1
2.7 Focus on backward compatibility. The
OrganizationUser provides the key connection to
studentpersonal, staffpersonal, and
studentcontactpersonal as well as schoolinfo. It can be
adopted immediately in 2.x environment.
3.1 Uses the new 3.0 PartyOrganizationAssociation
object to replace OrganizationUser. Therefore it is more
flexible.
In the next 3 diagrams, we show the “combined” view,
the 2.7 model view and the 3.1 model view.
SIF 2.7 IDM ProfileId
enti
fica
tio
n M
anag
emen
t Lo
gica
l En
tity
Mo
del
StudentPersonal
RefId
Student_IdPersonal_Attributes
OrganizationUser
RefId
PersonIdOrginalAssociationIdAssociationTypeOrg_IdStartDateEndDateAuthoritativeSourceId
IDM_Authentication
RefId
OrgUserIdIDP_Login_IdIDP_App_IdIDP_TypeStartDateEndDateAuthoritativeSourceId
IDM_Authorization
RefId
OrgUserIdApp_IdApp_FunctionStartDateEndDateAuthoritativeSourceId
StaffPersonal
RefId
Staff_IdPersonal_Attributes
StudentContactPersonal
RefId
StudentContact_IdPersonal_Attributes
SchoolInfo
RefId
Org_AttributesParentOrgId
IDM_Applications
RefId
App_NameApp_URIApp_Default_FunctionApp_Function_ListApp_Default_IDP_IdApp_IDP_ListStartDateEndDate
Design highlight and consideration Person vs. OrganizationUser
Person is longitudinally traceable and consistent.
OrganizationUser is more relevant in application identity and role-based access control context. OrganizationUser is conceptually equivalent to the union of StudentPersonal, StaffPersonal and StudentContactPersonal. In CEDS 3.0, OrganizationUser = OrgPersonRole
Authentication
SIF IDM data interchange does not really care that much about the specific authentication mechanism, as long as single-sign-on could be established.
Authorization
Similarly, SIF IDM data interchange does not enforce the RBAC mechanism in applications, as long as the authorization is honored.
Application
New 3.0 object that reflects the ecosystem reality
SIF IDM Service Workflow
IDM Workflow Diagram
IDM Workflow
1. OrganizationUser2. (StudentPersonl,StaffPersonal,StudentContactPersonal)3. Person ~ Optional4. EducationalOrganization ~ Optional
* Authentication
1. OrganizationUser2. (StudentPersonl, StaffPersonal, StudentContactPersonal)3. Person ~ Optional4. EducationalOrganization ~ Optional* Authorization
Target Applications (Portal, LMS, or other SSO Participants)
AppUser Management
(Person and Organization)
AppRBAC
Service
Identity Administration And Configuration
Facility
App Identity To Domain Provision and Synchronization Service
IdentityFederation
Runtime
Authoritative Sources (HR, SIS, SLDS)
AppProvisioning Source
(Person and Organization)
AppDomainAccessControl
Identity Administration
And Configuration Facility
Source Identity To Domain Provision and Synchronization
Service
Application Registry(Optional application
references populated through the Application Registration
Service or Manual Entry)
Application Profile
Identity Provider (Owned by SEA/LEA
Directory(eg. AD orLDAP or
NDS )
LogOn ID
Federated SSO
(eg. ADFS orSiteMinder
Or OpenSSO)
1. Application Registration (optional) 2. User Authentication Provisioning 3. User Authorization Provisioning4. Run-time SSO
1
2
3
4
2
3
The systems involved in the IDM workflow
1. Provisioning Source System a.k.a. IDAM
It could be SIS, HR, SLDS, or even individual application such as parent portal, but the best practice would call for an integrated ID management application (or process) for all ID sources to be aggregated and managed.
It should manage the organization roles and optionally application roles.
Optionally, the unique ID generation service might be attached to this system.
Optionally, the organization hierarchy, unique organization ID, organization relationship and other master reference data could be also managed here.
A Master Data Management process is highly recommended to manage the data governance, data quality service, deduplication, address validation, and other MDM processes.
It should be at least visible to the App Registry, and optionally, it manages the App registration process or even App Store.
2. Authentication provider, a.k.a. IDP, such as Active Directory or LDAP
3. Target Applications, aka SP, such as LMS, CMS, PD, etc.
4. SSO Management System, such as ADFS, Siteminder, OpenAM, etc.
Implement the SIF IDM Use
Cases A Usage Guide
List of Use Cases
Base Scope Use cases
A. IDP Provisioning/Deprovisioning.
B: Access Provisioning on Target System (Assuming SSO)
C: Authentication/Access Provisioning across 2 or More
Educational Systems (Without SSO)
* App Provisioning and Permission Mapping
Extended Scope and edge cases
D: Longitudinal Identity Tracking
E: User Transfer from One Organization to Another
Organization
A: Identity Provisioning on IDP
Use case
One or More applications want to use a single directory service to manage the user authentication. The first step is to provision the user or the directory service provider (AD or LDAP or even OpenID provider) from the source SIS or HR system.
(In SIF 2.7 environment) IDM Objects needed in IDP Provisioning Request/Response
OrganizationUser
The linked person object (StudentPersonal, StaffPersonal or StudentContactPersonal in 2.7)
*IDMAuthentication
Optional: The linked organization object (SchoolInfo, etc.)
A: Identity Provisioning on IDP
(In SIF 3.1 environment) IDM Objects needed in IDP Provisioning
OrganizationUser
The linked person object (if Longitudinal Unique and Persistent ID is not available, the Associated Person object will be equivalent to PersonInfo).
*Authentication object
Optional: The linked organization object (School, SEA, LEA or other EducationOrg)
Source: IDAM (Authoritative Provisioning Source System)
Destination: IDP
Steps: (Most Common Choreography)
1. The origin system send the 3 connected profiles to the IDP
2. The IDP generates the completed Identity Profile back to the origin system to acknowledge the completion of linkage
B: Access Provisioning on Target
System (Assuming SSO)
Use Case
One or More applications want to use a single directory
service to manage the user authentication and wants to
automatically create user access right for new
students/staff/parents without recreating the userID again.
B: Access Provisioning
Source: IDAM (Authoritative Provisioning Source System)
Destination: Target Apps (a.k.a. SP), for example, LMS system, student/parent portal, Library System, etc.
Steps: (Most Common Choreography) in both 2.7 and 3.1
1. If that the Target System (SP) already uses the shared IDP for authentication,
IDAM sends only the IDM_authorization object (2.7) or the Authorization object (3.1) to the target system
If the target system needs to generate its own version of the user profile, for example, first name, last name, etc., the personal information can be sent through the linked OrganizationUser and Personal objects.
2. Optionally, the target can acknowledge by sending the successful Authorization Object back to IDAM and also optionally, directly send email/SMS communication to end users to notify the completion.
C: Authentication/Access Provisioning across 2
or More Educational Systems (Without SSO)
This is very similar to the previous use case B. The only
difference is that the target system, instead of using
the separate IDP, is using its own user management
system for authentication and access control.
The profile exchanged are the same as case B and the
content difference is the IDPName, instead of the
external IDP such as ActiveDirectory or LDAP, is the
target application system’s user management page URI.
This way, the ID generation step is combined with the
Role Access generation step.
D: Longitudinal Identity Tracking
This involves the enforcing of uniqueness and persistence of
the Person Profile RefID across multiple Authoritative Source
System.
In the current proposal, we assume that the “source” system
for user provisioning guarantees the uniqueness of the person,
i.e., the source system knows that the elementary student
John Doe is the same as the middle school student John Doe
by referring to them with the same ID (or DNA sequence :)
In the case of multiple source systems, there need to be a
master data management process to deduplicate person
records and also merge/survive historical records.
E: User Transfer from One
Organization to Another Organization
If both organization’s systems are all referring to the same longitudinal PersonID, this process is very simple by just following Use Case A, B, and C (does not have to use SSO).
If such ID schema can not be enforced or the established system can not be easily migrated/upgraded, a MDM process must be established to enable a “combined” person store to link Person identities across multiple systems (similar to address book synch process)
For example, in the Tri-border use case, the tracking of the student movement can be achieved by requiring the “Original” Person ID when a student is moving into another state/school district. This way, the IDM profiles can be used backward to regenerate longitudinal Person history and persistence.
IDM implementation best
practices The SIF IDM Context
Discussion Points
Backward compatibility with 2.x Data Model
Implementation in application frameworks
SIF IDM objects have already been adopted by CEDS 3.0
Relationship between IDM profile and SIF infrastructure
Relationship between IDM profile and common security
protocols such as OAuth, SAML and openID
Use common app framework such as GoogleApp,
inBloom, etc.
Relationship between SIF IDM and Implementation of
Interoperability in SIF Zone
In the SIF Infrastructure Model, whether SOAP or Restful
API is used for transport, the security model and
interoperability model should leverage the IDM work.
If Restful API is used, the service provider would
probably use some variation of the OAuth for API
authentication. Prior to the API configuration, especially
for authenticated usage of the service, the id and RBAC
process must be established. The Use Cases A, B, C can
be established for ZIS as well as Zone Participant
Systems.
Identification Integration Options
Identification Integration (SSO) with SEA/LEA IDMs (also called
Identity Providers)
If the SEA/LEA already has dedicated IDM (IDP), there could be 2 authentication
integration schemes - Federated and Delegated. In both cases, the SIF
integrated applications could serve either as a Service Provider (applications
that requires authentication) or a conduit for other Service Providers
(applications) on the platform. SIF will provide not only the interchange
standards (profiles) and suggest business rules and best practices for
authentication to authorization mapping.
Federated Authentication (such as SAML)
Delegated Authentication (such as OAuth)
Third-party or hosted IDMs
If the SEA/LEA does not have a IDM that can support the SSO options natively, a
hosted identity manager (IDM) might store and manage information such as user
names, passwords, and roles, and provides a way for enabled applications to
access the identification credential that do not have a home in the SEA/LEA
IDM. The assumption is that such hosted IDM (such as Google Apps for Education
or other OpenID provider) might save the SEA/LEA the administration/IT cost.
Verify IDM integration readiness.
Identity Integration Services installation, validation, configuration and testing
Set up the SSO architecture and integration components
Might involve consulting service from SIF certified partners
Identity/Access Integration Life Cycle Infrastructure Set-up
IDM to Domain Entity Mapping
ID Provisioning Process
Data loading or conversion
Set up ongoing Sync process
Operation Process
SEA/LEA set up IDM integration SLA
SEA/LEA sign term of use (if IDM hosting is involved)
SEA/LEA adopt SOP (Standard Operation Procedure)
30
Directory Integration Process
(Implementation best practice)
31
Sample Implementation Steps for
SEA/LEA with AD
Set-up Steps
Assume the SEA/LEA has Active Directory
Install and configure ADFS 2.0 to enable SAML 2.0
Configure ADFS to enable Trust to target application
Ensure entity ID to AD userid mapping in application
(Optional) Configure AD to embed application roles
Integration Steps:
Use IDM profiles (Authentication profile, OrganizationUser profile, and optionally, Person Profile, Org Profile and Authorization Profile) to provision ID mapping from target application to AD
Configure asynchronous or batch process to maintain the ongoing IDM synchronization between AD and Application
32
Sample Operation Process
Ongoing Access Control
Establish district-wide Application/Task/Data access
Maintain access control mapping for additional application
Policy and authorization configuration
Establish Provisioning Approval List and Support Process
Establish Data Governance process
Formulate SLA and enforce process best practices
Define data and security standard operation procedures
Other related Infrastructure Services
Monitoring and Logging service (using SIF infrastructure service?)
Audit trail (using SIF infrastructure service?)
Real-world Case Studies
Australian Case Study – Nick Nicholas
Multi-tenant, multi-application ecosystem framework
such as RTTT Assessment Systems including Smarter
Balanced and PARCC
Instruction Improvement System or Learning
Management System implementation that leverages
Google Apps, Drop Box or other commercial COTS
applications.
Appendix: IDM Architecture
Framework Realm of trust; IDM integration service layers
The different realms of trusts
1. Public realm –
The IDPs serving such realm are open to individual and can
be provisioned without authoritative intervention. fb,
google, yahoo, live, skype, linkedin, twitter, sina, qq, etc
2. Organizational realm –
The IDP or directory (normally an enterprise DS such as AD
or application-centric IDM) is normally organizationally
provisioned and managed.
3. Mixed realm –
The future Prosumer application ecosystem such as
Blended Learning and Shared Learning Collaborative.
Identity Integration Service Layers
Hosted Directory
Store used by LEA/SEA
(Google, OpenID, etc.)
LDAP/SLDAP
Active
Directory
OpenSSO, OpenID,
OAuth, etc.
CA SiteMinder and
other commercial SSO
Solution
ADFS (Active Directory
Federation Services)
Authorization API
& Entitlement
Business Rule Engine
Identity to Domain
Entity Synchronization
Process
SIF Authentication
Provisioning
Process
Authentication
API Proxy (Custom)
RBAC and
Authentication
Best Practice
Customized Directory
Store and Legacy DS
(NDS, PKI/CA, etc.)
Directory Services
(Owned and Operated
By SEA/LEA)
Identity
Integration
Services
Identity
Lifecycle And
Access Mapping