SIF IDM 101: Identification

Management Profile

Introduction

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

A Primer of the SIF IDM Profile

Background for a comprehensive IDM profile

The new solution

The use cases

Logical IDM model

IDM workflow best practice (Also covered in IDM 102)

Migration path from 2.0 (To-be-covered in IDM 102)

The real-world story and next steps (To-be-covered in

IDM 102)

Appendix

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

The SIF IDM Profile

Solution

Scope, Logical Model, Individual Entity Objects, and

Recommended Workflow

Scope of SIF IDM Use Cases

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

IDM Logical Model 2013

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

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.

IDM Entities * Note: We primarily use the 2.7 entity names in this section.

For 3.1, the logic is the same, but the names and relationships

are a little different to reflect the new entities.

OrganizationUser

This object is the link from the IDM data to the existing

StudentPersonal, StaffPersonal, etc. in the current SIF model.

This is directly corresponding to the CEDS 2.0 OrgPersonRole,

which is an association of Person, Role and Organization.

The Ed-Fi model equivalents are Student/Staff/Parent.

For organization mapping, CEDS/Ed-Fi define them as

Educational Organization/Programs.

The time dimension (StartDate (required field), EndDate

(optional field)) would be the key aspect to identify the

LifeCycle of the OrganizationUser. This object would become

the key reference object for all identification propagation

across systems.

Application

Application Profile – The application System(s) that participates in the overall integration App Ecosystem where SSO and coordinated Access Control are needed.

App_Name and App_URI are for navigation and display

App_Default_Function could be used for service invocation (for example, within an EcoSystem, there could be several applications that provide “chat” functions or even “IdP” functions)

App_Default_IDP point to the Application that authenticate the users for this app. For example, the “ParentDashboard” application might be using “DistrictLDAP” as its ID Provider.

Authentication

Authentication Profile – to establish authentication map between OrganizationUser and IDP’s LoginID. This profile will also be used to provision or deprovision user from SIS/HR to IDP (Identity Provider such as Active Directory, LDAP, or OpenID provider).

LoginID as defined in the IDP Directory of the SEA/LEA institutions.

IDP_App_ID - the IDP where this user is provisioned on (for example, staff might use one IDP called “StateStaffDirectory”, and parent might use another IDP service called “OpenIDProvider” to log in)

OrganizationUserID – A reference to the OrganizationUser

StartDate

EndDate

Authorization

Authorization Profile – to establish role/permission map between OrganizationUser and Downstream Application’s role and permission. This profile will primarily be used to provision or deprovision user from SIS/HR to one particular educational system.

OrganizationUserID reference the OrganizationUser (

App_ID – Reference to the target application where this OrganizationUser is provisioned. For example, Hattie Leary as a Staff in Anoka will be mapped to Administrator in Library Management System.

App_Function is the function that the application is providing for the OrganizationUser. For example, Hattie is using “Moodle” to serve “LMS” function for her.

OrganizationPartyAssociation (3.x)

This object is almost functional equivalent to the OrganizationUser in the 2.7 logical model. There are several subtle differences:

The OrganizationPartyAssociation does not have start/end date, so it can be used to trigger a scheduled provision event.

“OrganizationUser” has a field “OriginalAssociationId” which can be used to store the StateID, EmployeeID, StudentID or other non-GUID type keys, while OrganizationPartyAssociation does not. For implementation purpose, it is would be easier to control data quality when keys can be checked against existing database keys. Therefore, OrganizationUser object is better suited when backward compatibility is required.

Person (A 3.x concept, also connected

to the 3.0 student object)

The objective for the person object is to establish the cross-

domain longitudinal reference link to any personal

information within the SIF framework. All personal and

demographical information will be referred to this object.

For identity management purpose, the information carried in

the Person Profile should be consistent throughout the

systems and first created from SIS/HR.

The reality is that a lot of the existing system does not share

master data management (MDM) for person and it is

recommended to have this person linkage to be optional

rather than mandated to allow existing system adoption of

the new IDM paradigm and allow continuous improvement.

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 2013

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

Appendix: CEDS Conceptual

Mapping to the SIF IDM

Profile (Source: CEDS)

Conceptual Model

Organizations People

Teaching, Learning,

Assessment

Roles

Time

27

All can be represented

as Roles

Key Concept: OrgPersonRole