SIF IDM Profile Introduction


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SIF IDM Profile Introduction

  1. 1. SIF IDM 101: Identification Management Profile Introduction Hattie Leary Richard Tong Vince Paredes Linda Marshall Linda.Marshall@nsip.EDU.AU
  2. 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. 3. Background for SIF IDM Profile Why do we need SIF Identity Management Profile?
  4. 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. 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. 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. 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. 8. The SIF IDM Profile Solution Scope, Logical Model, Individual Entity Objects, and Recommended Workflow
  9. 9. Scope of SIF IDM Use Cases
  10. 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
  11. 11. IDM Logical Model 2013
  12. 12. 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. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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
  18. 18. 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.
  19. 19. 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.
  20. 20. 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.
  21. 21. 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
  22. 22. SIF IDM Service Workflow 2013
  23. 23. 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
  24. 24. Appendix: CEDS Conceptual Mapping to the SIF IDM Profile (Source: CEDS)
  25. 25. Conceptual Model Organizations People Teaching, Learning, Assessment Roles Time
  26. 26. 27 All can be represented as Roles Key Concept: OrgPersonRole
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.