Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SIF IDM Profile Usage Guide - Presentation at the 2014 annual conference


Published on

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.

Published in: Education
  • Be the first to comment

  • Be the first to like this

SIF IDM Profile Usage Guide - Presentation at the 2014 annual conference

  1. 1. SIF Identification Management 2.7/3.1 Profile Usage Guide Hattie Leary Richard Tong Vince Paredes Linda Marshall Linda.Marshall@nsip.EDU.AU
  2. 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. 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. 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. 9. Review of IDM Logical Model Session 101
  10. 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. 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
  12. 12. 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
  13. 13. SIF IDM Service Workflow
  14. 14. 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
  15. 15. 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.
  16. 16. Implement the SIF IDM Use Cases A Usage Guide
  17. 17. 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
  18. 18. 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.)
  19. 19. 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
  20. 20. 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.
  21. 21. 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.
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. IDM implementation best practices The SIF IDM Context
  26. 26. 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.
  27. 27. 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.
  28. 28. 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.
  29. 29.  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)
  30. 30. 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
  31. 31. 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?)
  32. 32. 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.
  33. 33. Appendix: IDM Architecture Framework Realm of trust; IDM integration service layers
  34. 34. 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.
  35. 35. 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