1. 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
2. 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
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. The SIF IDM Profile
Solution
Scope, Logical Model, Individual Entity Objects, and
Recommended Workflow
10. 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
14. 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.
15. 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.
16. 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.
17. 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.
18. 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
19. 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.
20. 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.
21. 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.
22. 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
