A general guide on how to use SIF IDM V2.7 and V3.1 for identity management in education technology solutions, especially for complex multi-vendor, multi-application frameworks. Includes the typical use cases such as provisioning and SSO establishment, workflows, best practice in U.S. and Australia implementations, and architectural contexts.

1. 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

2. 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)

3. Background for SIF IDM
Profile
Why do we need SIF Identity Management Profile?

4. 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?

5. 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.

6. 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,

7. 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

8. 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

9. Review of IDM Logical Model
Session 101

10. 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.

11. SIF 2.7 IDM ProfileIdentificationManagementLogicalEntityModel
StudentPersonal
RefId
Student_Id
Personal_Attributes
OrganizationUser
RefId
PersonId
OrginalAssociationId
AssociationType
Org_Id
StartDate
EndDate
AuthoritativeSourceId
IDM_Authentication
RefId
OrgUserId
IDP_Login_Id
IDP_App_Id
IDP_Type
StartDate
EndDate
AuthoritativeSourceId
IDM_Authorization
RefId
OrgUserId
App_Id
App_Function
StartDate
EndDate
AuthoritativeSourceId
StaffPersonal
RefId
Staff_Id
Personal_Attributes
StudentContactPersonal
RefId
StudentContact_Id
Personal_Attributes
SchoolInfo
RefId
Org_Attributes
ParentOrgId
IDM_Applications
RefId
App_Name
App_URI
App_Default_Function
App_Function_List
App_Default_IDP_Id
App_IDP_List
StartDate
EndDate

13. 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

14. SIF IDM Service Workflow

15. IDM Workflow Diagram
IDM Workflow
1. OrganizationUser
2. (StudentPersonl,
StaffPersonal,
StudentContactPersonal)
3. Person ~ Optional
4. EducationalOrganization
~ Optional
* Authentication
1. OrganizationUser
2. (StudentPersonl, StaffPersonal,
StudentContactPersonal)
3. Person ~ Optional
4. EducationalOrganization ~ Optional
* Authorization
Target Applications
(Portal, LMS, or other SSO Participants)
App
User Management
(Person and
Organization)
App
RBAC
Service
Identity Administration
And Configuration
Facility
App Identity
To Domain Provision and
Synchronization Service
Identity
Federation
Runtime
Authoritative Sources (HR, SIS, SLDS)
App
Provisioning Source
(Person and
Organization)
App
Domain
Access
Control
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 or
LDAP or
NDS )
LogOn ID
Federated
SSO
(eg. ADFS or
SiteMinder
Or OpenSSO)
1. Application Registration (optional)
2. User Authentication Provisioning
3. User Authorization Provisioning
4. Run-time SSO
1
2
3
4
2
3

16. 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.

17. Implement the SIF IDM Use
Cases
A Usage Guide

18. 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

19. 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.)

20. 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

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. IDM implementation best
practices
The SIF IDM Context

27. 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.

28. 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.

29. 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.

30.  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. 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. 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?)

33. 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.

34. Appendix: IDM Architecture
Framework
Realm of trust; IDM integration service layers

35. 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.

36. 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