Refining the Credential Management Controller Process

DRAFT DRAFT DRAFT

TIER Registry and DATA and API workgroups have provided an the TIER Entity Registry  - Identity Onboarding Flow Architecture during December 2017 and January of 2018.  Additional decomposition and advice related to components of this flow are defined to assist institutions implementing TIER components and Identity Service Applications. 

An architecture flow and event document for  TIER ENTITY REGISTRY - Identity OnBoarding  can be found at 



The intent of this entry is to provide a guide at a high level for integrating flows for Credential management into the Onboarding process.   It is intended to describe a pattern for institutions to use when building a Registry Onboarding process.  

Institutions may elect to utilize existing Credential management components and UIs or to retool using Midpoint or other tools.   

TIER - Credential Management Controller Flow

Considerations about Credential Management 

A simple manner to think about your identity system data flows can be considered in two fundamental flows, Identity Onboarding and Identity Provisioning and Authorization. Simply processes to get data into the ecosystem and processes to get data downstream or out to the applications relying on the access management services.

  •  Onboarding activity defines the entities in your Identity Service Ecosyystem.  Activities include population of you entity registry, assignment of an institutional identifier, matching input from multiple SORs, recording and /or assigning user accounts for the entity (Credential management Controller), triggering Subject info into the Groups Update Controller, and triggering the establishment of some  basis, and reference groups into the Groups component.  Onboarding does include the provisioning of downstream services.    
  • Assigning credentials at an institution or linking credentials for External credentials provides your identity system with knowledge of those individuals who are logging in and may log in to services at your institution.
  •  Building application groups, extending and refining reference groups, setting rules in the grouping component.  Passing this information to the provisioning tools within the ecosystems and communicating those data to the services. 
  • Id Match Service is a portion of the onboarding process invoked by the Registry Update Controller.  The ID Match may utilize username, (netid principal)  as a matching vector. 
  •  The institution should consider some basic best practices regarding Credentials. These are basic not necessarily simple.
    • Will you allow at some now or in the future External Credentials to access services? 
    • Can an entity have more than one credential associated , used, or controlled by the entity?
    • Will the Institution allow reuse of credentials.
    • Secrets (password) and factors for securing the credential are stored in safe and very few places.
    • How are the Secrets and factors managed.  Self Service, helpdesk, both ? 
    • Is there Policy, Standards and procedure for these Identity service Activities. 
    • You will find other similar questions in this key onboarding process. 
    • The activity will likely need cooperation and input from management/staff managing the various SORs.
  • Adding someone to the registry does not mean they have been given (provisioned access) .  Rather it means they have been assigned an institutional identifier.  Following the assignment of the institutional identifier they can be linked to an external username or processed to acquire one or more institutional usernames.
  •  The grouping processes when forwarded into the provisioning space will create the access policy.  Grouping can recognize subjects with and without credentials.

From workgroup input ( in progress:)

      1. Individuals have multiple sets of credentials

      2. What is our terminology for ‘username’, ‘NetID’ vs ‘credential sets’ vs ‘accounts’

        • Users may have multiple Accounts (whether or not the user has associated credentials associated with the account)

        • “NetID” is identifier associated with the institutionally-assigned main user account

        • Profile (the core digital identity for a person) then they have 1 or more additional accounts, some local, some external

        • User maintains some attributes of their own Profile: Preferred name, etc.

        • midPoint documentation uses “User” for what we’re calling “Profile”

        • “My policy maps a given Profile to (1 or more) Accounts”

        • Not all Profiles include a NetID. E.g. Student Applicants bring their own credentials. External identity encompasses federated and ‘social’ identities; ‘social’ scares concerns people

        • We commit to consistently using (possible edited versions) of these terms


Step-by-step guide


Determine your Credential management control processes in your entity registry. 

  • Flow 6 :  When a person is added / updated to the Person registry an Add/Update Institutional Person message (event) is generated and placed in motion via API or messaging protocols.  
    •  The Credential Management Controller should examine the change to determine what if any action should be taken based on this notice.
    •  Institution may choose to update certain institutional groups at this  notice. 
    • Credential management Controller will receive the Institutional Person event.
    • Inspection of this receipt will determine  how this Add/Update should be processed.
  • Flow 7 Received info is prepared for actions to be taken
    • Info to transmit
      • Institutionalindetifier,
      • Credential Identifier,
      • (netid, Account, username),
      • action/event
      • ?
    •  New credential to be created
    • Register /link an external credential
    • Inactivate a credential
    • Change Password/Secret
    • Forgot Credential
    • Invite/Claim
    • other (replace, expire, Two or multi factor)
  • Flow 8  User activates Credential
    • Update Credential Store(s)
  • Flow 9 Institutional Person Credentialed Message

Other considerations for managing the IdMatch service. 

  1. Additional references
    1. TIER Minimal Person Schema
    2. New person from SOR Narrative
  2. Should the Credential(s) be used in the ID Match.
    1. This is backfed to the IdMatch data this is a good feature for ongoing management between these data stores..    
    2. This enables the ability to match on usernames that have been linkedto the entity.  If SORs are aware of that id it provides a very reliable match.
  3. Periodic updates of Id Match database from the registry.
    1. IdMatch  database contains certain information that should be periodically refreshed from the source.  (name, phone, etc)
      1. SOR-Registry Strawman ID Match API (see the Update Match attributes section)
      2. periodic refresh
      3. event based update when changes occur to the data elements in the Match database.
      4. both ( this would be the preferred solution if it can be supported.)
  4. UI for Managing Credentials 
    1. Use default ADMIN UI in the TIER ID Match component.
    2. Develop a UI specific to your needsmore to come... 

  5. Data that may be of interest to save  related to user name and credential management

    1. All strings case insensitive, all indexed


      Identifiers
      RegistryID or RID (either name) (TIER INSTITUTIONAL ID)
      128 string
      Req’d Uniq
      Primary key component
      Principal (username)
      256 string
      Req’d, Not uniq
      Primary Key component
      LinkedID or LID (either name)
      128 string
      Not Uniq, Not req'd
       
      SOR ID
      128 string
      Not req’d, not uniq
      Principal Resource Type TIER
      64 String
      Not Uniq – REQD – From Table of Values ( Person, Group, Application, Email Alias,…)
      TIER FriendlyName
      128 String
      Not Uniq – REQD –
      TIER Name (used with Person resource type)
      honorificPrefix     String 32
      Givenname           String 64
      Middlename         String 64
      Familyname         String 64
      honorificSuffix    String 32
      Formatted            String 256 (created by combining the 5 name part above in sequence shown)
      These are not Not required, not unique,
      TIER email value
      Not unique, Not required
      TIER phonenumber value
      TIER phonenumber type
      Not unique, Not required, Type required with number,  (cell, landline),  

      Datecreated
      Not unique,Required, datetimestamp
      Dateinactivated
      Not unique, Not required, datatimestamp
      Endtimestamp
      Not unique, Not required, datetimestamp
      TIER Status (active, inactive, …others being defined)
      Not unique, Required,  String 16
      This is used to track the lifecycle of an entity through a series of states.
      TIER Updating Entity ID
      Not unique, Required, string 256
      TIER Updating SOR
      Not unique, Required, string 128
      TIER Protect
      Not unique Required, Boolean (true, false)

There are more steps (1 thru 5 and 10 thru 11 from the identity onboarding flow architecture) to consider related to the Identity Onboarding, however since this document is focusing on the Credential Management Controller they are not covered here.  The Registry Update Controller and the Groups Update Controller are treated in separate confluence documents.