SIF Identification

Management 2.7/3.1 Profile

Usage Guide

Hattie Leary Hattie.Leary@anoka.k12.mn.us

Richard Tong rtong@amplify.com

Vince Paredes vparedes@sifassociation.org

Linda Marshall Linda.Marshall@nsip.EDU.AU

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