“The shoemaker’s children always go barefoot” 🙂

This is somehting that can discribe our SAP IdM authorization structure/concept …there is no such. It’s a rare case, when we have to implement one and there is no standard connector or approach for that.

With this blog, I want to present one possible direction with which we can cover this topic.

1-st we have to think about the technical part

SAP IdM connector for SAP IdM. Custom connector with 2-reposiotry types – Local/Remote, based on the systems we will connect (use as example the standard AS JAVA connector).

IdM connector – overview

• • SAP IdM Local connector (IdM will provision access for itself)
    • create account
      • Standard UI authorization account – standard account created based on UI authorizations
      • Eclipse access (schema and package accounts) – IdM schema account, based on IdM schema/package access

IdM Create user example

• • • delete account
      • Standard UI authorization account
      • Eclipse access (schema and package accounts)
    • assign access
      • Standard/custom UI access
      • Eclipse access (schema and package access)
    • remove access
      • Standad/custom UI access
      • Eclipse access (schema and package access)

Note: for the schema/package authorization keep in mind we have standard procedures that can be used to provide the needed/requested access.

Note: the schema/package authorizations will be needed only for a few authorized users and you have to make sure that only those will be created as such.

• • SAP IdM Remote connector (OPTIONAL)

IdM will provision access to a remote SAP IdM system – here we can go wilde and a bit overboard. Depending on the level of automation you want to have, I will list a few options:

• • • IdM connector using LDAP (going for the VDS/stanging area option) – depending on the time you have to spend over this connector, this is a bit overboard
    • IdM connector using REST (use the REST and call the remote IdM system)
    • IdM connector going through IPS and doing a PROXY call to the remote IdM system – if you wnat to play with the SCIM/IPS integrations
    • IdM connector using DB connection to the RT schema – not a real time connection, but storing data in temp tables scheduled to run on the remote systems
    • IdM connector using remote dispatcher (I know you all will be think of that).. but this will be listed under the section – a bit overboard and too exotic 🙂

Note: depending on the way your system provision access to IdM DEV/QAS/PRD the remote connector is optional.

Note: here I’m listing possible directions, not all of those were ever used in my real life implementations… make it as simple as possible.

• SAP IdM/UME authorizations (this one is not a part of this blog topic)
  • here we have the standard AS JAVA SAP connector

2-nd we have to cover the IdM authorization concept 

2.1. SAP IdM Privileges

• SAP IdM standard access – MX_PRIV…. privileges
• SAP IdM UI custom Access Control Privileges (no system specific)
  • this type of privileges will be similar to the standard ones and they won’t be system specific in order to use IdM transport from DEV to QA to PRD
• SAP IdM package and schema privileges
  • those privileges will be system specific and they will have the standard IdM triggers to trigger assignUserMembershopt/revoleUserMembership plugins
  • important remark here is that in order to have package access, the account should be created inside Eclipse schema (developer/developer_admin)
  • depending on the level of separation you want to have you can create your IdM package privileges on a package level or based on authorization level (viewer/developer/owner…)
• SAP IdM trigger privileges (mapped to IdM non system specific privileges)
  • those privileges will be system specific and they will have the standard IdM triggers to trigger assignUserMembershopt/revoleUserMembership plugins
  • depending on the way you structure/use your IdM landscape, you migh not need those

2.2. SAP IdM Business Roles – keep in mind how you want to build the BR’s and the relation between system specific privileges and NON-system specific ones.

In each IdM related BR we need to have IdM BR trigger privilege, so when UI authorizations are requested the correct landscape will be updated (DEV/QA/PRD…), as when we request access for a Remote IdM system, the access needs to be provisioned somehow.

3-rd step is the connection and initial load of an IdM system

3.1. Connect the local IdM system. You should always start with the local system, as at the end the access requested for a remote system (in case you have such) will be treated as access for the local, when it comes to it….our own IdM inception scenario 🙂

• import the custom.connector.idm package
• create IdM Local repository
• initial load/create account attributes, system/only privileges
• initial load/cration of custom/schema/package/IdM trigger privilegs
• load exisitng accounts/assignemtns
• activate system triggers
• activate daily scheduled jobs

3.2. Connect the remote IdM system (OPTIONAL)

• import the custom.connector.idm package
• create IdM Remote repository
• initial load/create account attributes, system/only privileges
• initial load/cration of custom/schema/package/IdM trigger privilegs
• load exisitng accounts/assignemtns
• activate system triggers
• activate daily scheduled jobs