Considerations in connecting SAP IdM with Leading Identity System(s)

[terovirta]

I thought I would share some of my experiences about IdM solution design and start with connecting IdM to Leading Identity System(s). I started in new IdM-project some time ago and my first task was to come up with an IdM-concept. In order to facilitate the workshops and discussions I put together a set of questions that I must get an answer. For this blog I included some descriptive text to give background why I think the topic/question is relevant.

All of this blog is from my personal experience or thoughts, not the full nor only truth. Although I tried to re-write it as generic as possible it might be missing an angle or two.

But I hope it helps someone new to the SAP IdM and especially when SAP HCM is the Leading Identity System.

Integration to Leading Identity System

The identity lifecycle and various status changes of the user record in IdM should happen in controlled fashion that works as designed/according to requirements. Identities normally map to employees and the identity/employment data comes outside IdM and the lifecycle is usually controlled by events that are outside of IdM, like hiring or firing.

There are exceptions like technical user accounts or external workforce. Those accounts may not have an existing dedicated system where they're managed, so the full lifecycle of them can be done in IdM. Developing a set of UIs and background batch jobs that enable for example the basic administration of contractors can be achieved quite easily.

Questions:

• What are the Leading Identity System(s)?
• Single system vs. multiple systems?
• What types of identities are supplied by Leading Identity Systems?
• Attributes / data model
  • What will be the unique identifier (MSKEYVALUE) of the user entry in IdM?
  • What are the mandatory attributes for the user entry in IdM (plus Target Systems) and can the Leading Identity System supply all of them?
  • Does the user entry have to be enhanced with data from other system? Any transformation IdM must do the attributes?
  • Does the Leading Identity System supply an attribute/field that can be used in detecting the employment status or does it supply start/end dates?
• Technical points in integration
  • What systems are involved? Technologies? Protocols? Frequency? Configurable out-of-the box interface like SAP HCM or LDAP or custom-interface?

Data Model

I typically start working on data model immediately, that's why the attributes are relevant. The data model sounds fancier than it actually is, basically a spreadsheet having an attribute map between IdM and Leading Identity Systems and Target Systems. Any data transformation rules can also be documented to the attribute map, for example if IdM is supposed to generate the MSKEYVALUE or email-address. It should also be highlighted which system "owns" which attribute, what can be maintained in IdM, what is mandatory/relevant attribute for each system and what attribute value change is relevant for each system (what attribute should trigger Modify for each target system).

Types of identities/User Entries

Questions:

• What types of identities does the future IdM-solution handle:
  • Just employees / internal users?
  • Also external users?
    • Subcontractors
    • Suppliers
    • Partners
    • Customers
    • who else?
  • What is the Leading Identity System for each?

MSKEYVALUE

The unique identifier of the user entry in IdM is an attribute called MSKEYVALUE.

In most of my projects the leading Identity System has been SAP HCM. The easiest solution integration-wise is that HCM is already storing the username to the SY-UNAME field of InfoType 0105 which would map into MSKEYVALUE (by the "standard" attribute mapping in the HCM to IdM-interface). This way the problem with unique value is put to HCM which simplifies the IdM-solution. But on the other hand I've seen an awkward process in HR-dept to generate the username, so IdM autogenerating it and writing it back to IT0105 can also make the process better.

I've also had requirements to generate the MSKEYVALUE based on HCM data or use Personnel Number as MSKEYVALUE.

Questions:

• Where to get the unique id/MSKEYVALUE for the user entry?
  • Is it supplied by Leading Identity System? If the Leading Identity System is SAP HCM what field is going to be mapped to the MSKEYVALUE:
    • IT0709/PERSONID_EXT
    • IT0105/SY-UNAME
    • IT0000/PERNR
      • If it is tied to IT0000/PERNR will the personnel number ever change? What should happen in IdM if the Personnel Number changes?
  • If the Leading Identity System is not SAP HCM, what (hopefully unique) field is mapped to MSKEYVALUE?
    • for example; samAccountName from AD? uid-attribute of LDAP?
    • is the value unique or must IdM be adapted somehow?
      
  • If the field is not supplied by Leading Identity System:
    • does IdM generate the MSKEYVALUE based on Leading Identity System data?
    • does IdM generate the MSKEYVALUE based on other means, like just an auto number?
    • what data integrity checks are needed? LDAP/AD-lookup? SAP HCM IT0105/SY-UNAME lookup?
• Where will the MSKEYVALUE go?
  • Which Target Systems will have the MSKEYVALUE as username? Does the length or format of the Target System username affect to MSKEYVALUE?
  • Does the generated MSKEYVALUE need to be updated to SAP HCM IT0105/SY-UNAME-field?

User Entry Status

The user entry in SAP IdM does not have status as such. There are two attributes can be used in handling the status or replicating the status to target systems.

• mx_disabled (true/false) => can be used in disabling the user in target system, ie. prevent login
• mx_inactive (true/false) => can be used in deprovisioning, it makes the user entry inactive and hides it from active db-views and UI.

It is also possible to have a custom-attribute to represent the status of the user record in IdM or display values from leading Identity System, for example displaying the employment status of the user from SAP HCM.

The functionality tied into the mx_inactive differs a lot between the different versions of SAP IdM. Special consideration should be used when planning using the attribute. With the current Sp9 patch level that I am working with, inactivating the user automatically de-provisions all the access and re-activating (setting mx_inactive=false) reprovisions all access user had before inactivation (which may not be desirable).

(Note that the booleans in IdM work so that if the attribute exists it means logical true and no attribute for the record or removing the attribute means logical false.)

Questions:

• How is the user’s status in Leading Identity System mapped to SAP IdM?
  • If SAP HCM, how to map employment statuses to mx_disabled and/or mx_inactive?
  • If Active Directory, how to map userAccountControl to mx_disabled and/or mx_inactive?
  • If any other system, how to map the statuses to mx_disabled and/or mx_inactive?
  • If no status but validity dates are sent, what happen should happen in IdM when validity end is met?
  • Any other means of identifying the identity status change from Leading Identity System?

Joiners/Leavers/Transfers processes

Hire

Big benefit of IdM is the automatic on-boarding and provisioning process. A lot of automated provisioning actions can be built into on-boarding.

Questions:

• Any special processes in on boarding like approval steps (for example when the Leading Identity System is not 100% trusted) or will the identity be written into IdM as-is?
• Will the employees starting in future be imported once they exist in Leading Identity System? (so the access could have been requested and put into place for the first day)
  • If SAP HCM is the Leading Identity System, then the integration step that moves the employee data from Staging to Productive Id Store must be configured so that at least the mandatory attributes are written immediately to Productive Id Store (by default the future values are stored as pending values that become visible once the validity start date is met).

Technically the on/off-boardning processing can take place in the event task that writes the identity to Productive Id Store or event tasks in Productive Id Store.

Withdrawal

Along with the hire and automatic user creation the other big benefit of automated identity management is the automatic off-boarding and de-provision.

Questions:

• What happens on withdrawal?
  • Is the identity kept in IdM to reserve the MSKEYVALUE or other unique attributes? If so what status does the withdrawn entry have disabled vs. inactive?
  • Any grace period before losing any access? Same rules for all target systems?
  • If the user entry is to be deleted, is there a grace period before the entry really is deleted? Can a new user have the same MSKEYVALUE?
  • Any requirements on recovering access on:
    • re-hire
    • employee changes mind and does not exit
    • expired contractor or temp gets an extension
    • key person or C-title holder leaves, any emergency disabling of access?

Long Absence

What happens to the user entry during long absence (like maternity/paternity leave, study leave, long illness..) can vary a lot depending on the corporate or legal practices.

Questions:

• What happens on long absence
  • Does the user log-in to any systems during absence? (for example to see electronic pay-slip in SAP HCM’s ESS?)
  • Is the user disabled without losing any access during the absence?
  • Is any access removed?

Rehire

Questions:

• Will there be a new MSKEYVALUE on rehire?
• Will the old access rights be restored back?

Position / Organization Change or change in any other attribute that drives access

Questions:

• Any access driven by position (or other organization-related HCM-attribute)?
  • Context based assignment?
  • Dynamic groups?
  • Does the email-address change (to have a country specific domain name)?
  • Does the AD-container of the user change (if the "LDAP-path" has organisational data)?
  • Does any of the usernames change if any country specific prefixes exist?
  • What rights must expire that are driven by current location or organization specific attributes?
• Any grace periods if access is driven by attribute value and old access must remain for a while? (adding attribute validity to existing attribute value)

Employee Name Change

Questions:

• How is the change replicated to IdM? Just 1:1 immediate change or are there any legal matters or policies involved or for example does the employee have to request to have the new name(s) in the IT-systems?
• What attributes are driven by employee’s first/middle/last names and how should the change be reflected in IdM?
  • MSKEYVALUE?
  • Email-address and proxy email-addresses?
  • Usernames to Target Systems?
  • Display name?

Concurrent Employment and Personnel Numbers in SAP HCM

If Personnel Number is used as MSKEYVALUE it should be noted that Personnel Number can change (depending on the HCM solution). Also, in the HCM data model there are two personnel number fields; PERSONID_EXT and PERNR. The former field means roughly the "unique identifier of the employee in HCM" and the latter as the "unique identifier of the job contract". For the first "contract" the value of the Personnel Number field is the same as Person Id Ext.

The employee can have multiple job contracts:

• the employee may be a temp that gets new contract after the previous one has expired
• the employee may be a temp that works for different organisational units in same HCM-implementation (concurrent employment scenario)
• the employee may be going to expat assignment to another country / org unit (or may be returning from one)

Generally it is safer to map the Person Id Ext to MSKEYVALUE as it won't change.

It should be noted that HCM will export the old personnel number with employment status “withdrawn” and new personnel number with “active” employment status, the IdM solution must be configured accordingly.

External contractor becomes employee or employee becomes external contractor

With todays requirements for flexible job market I guess there are more contractors than ever, so most of the IdM-projects have had something special for contractors vs internals.

Questions:

• Will there be new MSKEYVALUE in the employment change?
• If the same MSKEYVALUE is kept what happens to any attributes that highlight that user is “external” or "internal"?
  • email address (for example if email has prefix, like “ext-“)
  • displayname (for example if displayname has word “external” for externals)
• What happens to existing access rights?
  • Does the user have to re-apply for them?
  • Are rights automatically moved to new identity if the job role stays the same?