For those of you who attended SAP TechEd in 2018, you might have noticed the diminished intensity of SAP Identity Management sessions, which include the name of the product directly in the session name. Even the Roadmap session (the only one to mention it in its title) was somewhat not very informative about the future of the product and what will happen with it in the next 5 to 10 years. However, at a second glance, SAP IdM was present, just under the hood. It was part of multiple sessions on cloud identity management, where it played an important role in various hybrid scenarios.
SAP Identity Management 8.0 plays an important role in both on-premise and hybrid scenarios for homogeneous and heterogeneous SAP/non-SAP landscapes
For those of you, who can't wait for the resolution of the title, feel free to skip to the end of the blog post, where the conclusion will reveal the mystery title. For everyone else, our journey will not start with the basics of what SAP IdM is and what the product is all about, rather I will list the most common functionalities of the product that are missing or not user-friendly to use and how you can overcome those on your way to a nearly-perfect identity management system.
First in the list comes the largely outdated end user interface of the product. Most (not all) of the SAP solutions have received their part of the Fiori pie and now shine in their new armor being more appealing, easy to use and mobile friendly. SAP IdM did an attempt to catch the wave already back in the 7.2 release, but apart from releasing a simple self-service static UI in SAPUI5, nothing else ever came to light. The reasons behind were multiple, but to focus on the two most important - incomplete and outdated REST v1 interface (at the time) and extremely complex dynamic generated Web Dynpro end user interfaces. This deadly combination pointed only in one direction -> SAP IdM won't have a Fiori end user interface anytime soon. However, thanks to the SAP Partner network, the above statement didn't really come true. Solutions to the problem started evolving - from simple to complex, from just showing the important information to the end users, to offering them comprehensive Fiori UIs streamlining their every day job. All those add-on solutions had one thing in common - they were re-creating the IdM UI the way partners saw it through their eyes. In fact, what the customers wanted was just the same logic they had in the past with Web Dynpro, but gaining the benefits of Fiori out-of-the-box. One of the many reasons for that was simple - migration! Many customers already have used SAP IdM for some years and dropping all their UI Forms configurations to start from scratch was not really an option. So was it possible to have it all - the flexibility of the IdM Forms with the benefits of SAP Fiori all in one dynamically generated UI. The answer is - YES! Here is a sneak-peek:
Business roles were, are and will be an important functionality of SAP IdM. They allow customers to group privileges, based on certain person attribute values (keys), from different source systems into one common Role that symbolizes a certain job definition within the company - e.g. Accountant. The role for such position would ideally contain all privileges from all target systems, where an accountant will be active including SAP, non-SAP and even systems that are not directly connected to SAP IdM (more will follow in the next chapters - e.g. Manual repositories). The easiest way to maintain and upload such an access list using standard SAP IdM functionality is by loading a CSV formatted file in a job within the IdM Developer Studio or through the Web Dynpro user interface. As you are well aware both are not the most user-friendly interfaces, let alone assigning someone not familiar with the task to do it. From the real-world examples we have had in the past, I've rarely had a case where the responsible for that access list was someone who also knew SAP IdM in detail. A lot of questions start popping up:
Questions can continue, but let's focus on what can be achieved outside of the standard solution. Some of the functionalities are available if we add SAP GRC or SAP IAG to the landscape, but still those would cover only the SAP world, unless additional add-ons and/or connections are setup. The perfect solution would be one that provides a user-friendly interface to the person handling the access list with proper validations and feedback in place, easy roll-back options, versioning, delta functionality and context creation/assignment. Does it exist? The answer again is - YES! Below is a sneak-peak:
When it comes to a running SAP IdM system, nothing is more important than making sure that this system is operational and functional at all times. Unfortunately, the standard means that SAP brings out of the box are not really the latest and greatest when it comes to that. The three main components that require monitoring are the tasks & jobs execution, the dispatchers' state and the processing queue. If any of these three gets stuck or overloaded, then nothing good is awaiting your SAP IdM system. Having an add-on that notifies you before things go wrong, might make the difference between a working and a non-working system. Adding the ability to start/stop your dispatchers remotely from one central place is a nice functionality that may spare you a lot of remote desktop connections in case you have multiple dispersed dispatchers running. Below is the sneak-peek:
Mass changes have always been a burden in SAP IdM, not because they are complex to execute, but because they do mass operations in your system, which outcome is very hard to predict and once things start going the wrong way, it is very hard to say, which of your 100 changes didin't happen and why. The demand for more control, readable audit trail and proper user interface is growing with every new failed attempt for mass change. If the only thing you did so far was use a job with an uploaded CSV file attached to a complex script to do the job, forget about this extremely dangerous and un-friendly way of doing things. Say hello to a Fiori interface that guides you through the process, doesn't allow typos and writes every action you perform in a readable audit trail. Mass data changes, mass access updates, mass user lock/unlock - all included in a must have add-on for every SAP IdM implementation. Check out the sneak-peek below:
The default implementation of SAP IdM doesn't come with a self-service task for password change. However, to create one is rather simple. This simplicity, unfortunately, also brings certain restrictions. Probably the main one is that the user interface is still Web Dynpro (e.g. not mobile friendly). Another one is that the interface does not provide any feedback whatsoever as to whether the password has actually been changed in the target systems. This is standard SAP IdM behaviour, since IdM keeps only one central password, which is sent to all connected target systems. The process of changing the password in each system is a separate one and is not tracked by the user interface, so every time you change your password - the message would say - "Your password has been changed successfully." Nice, but not always true. There might be certain restrictions in the connected systems, which cannot be implemented within the SAP IdM password policy, because they do not apply to all systems - e.g. combination of certain characters might not be allowed, history of passwords might be different in the different systems, etc. The only way to overcome such obstacle is to have a separate status per connected system. This is what our add-on brings to the table - full transparency when it comes to password change/reset. You will always know if anything went wrong, change your password only in the systems you want and receive proper feedback when the change has actually happened in the target system. Follows the sneak-peek:
In most SAP IdM implementations the identity management system is the central point of truth when it comes to user access and sometimes also to user master data (depending on the setup). It also happens that sometimes customers are sceptic as to how good SAP IdM can do its job and leave back-doors in the target systems, which allow users with sufficient privileges to modify master data or even access for users (e.g. in Active Directory). Those direct changes in the target system could be very harmful to how SAP IdM operates and should be avoided at all costs. A common way to solve such a challenge is to do a sync overnight from the connected systems and "inform" IdM about any changes that might have appeared. This approach, however, has one major flow - namely, was this access really added, because it was needed, or because someone wanted to gain advantage, which is otherwise not possible through SAP IdM (because of the approval process, SoD checks, etc.). Even if access changes are forbidden in the target systems, master data changes might be as well a great liability. A simple example is, if certain attribute value is changed and this particular attribute is responsible for a context assignment of privileges that give administrative rights. This would be a serious breach of security. While this phenomenon cannot be blocked or completely forbidden, it can be at least monitored and reacted properly upon. A friendly Fiori report can be available for every security admin to check at any time and react adequately to changes performed in the target systems (e.g. accept them or overwrite them with the data in IdM). The sneak-peek:
Connectivity has always been one of the strong sides of SAP IdM. Offering a number of standard connectors for SAP and non-SAP systems, the selection is further enhanced by the large partner network. On top in IdM 8.0 SP06 hybrid connectivity with the SAP Cloud Security services was introduced, which opened a whole new world of possibilities. The implementation of a custom connector to a system that is not supported out-of-the-box by SAP IdM is not a rocket science task for experienced consultants, but if you have to scale that to a multitude of systems with different interfaces, things might get a bit out of hand. The problem solver in this case might be a generic web service connector that can adapt to any SOAP interface from the target system and connect it easily in the SAP IdM process. Using the add-on, connecting target systems that support SOAP connectivity becomes an easy and repetitive task.
Workflow capabilities have been drastically improved in the SAP IdM 8.0 release, but they are running behind when compared to the other SAP workflow technologies like SAP BPM or SAP Cloud Workflow. While SAP IdM workflow is completely sufficient for simple approval flows and processes that stay inside the SAP IdM context, things start to reach the limits of the solution, when we have to connect an external system - e.g. a rules framework to check some conditions. SAP IdM workflow is quite limited when it comes to that. Also, if you have to build a rather complex process with returns to previous steps, error handling, notifications, SLAs, intermediate message events, etc., then you definitely need to think about an alternative. If you are already cloud minded, then you might consider the SAP Cloud Workflow. However, if you are feeling a bit skeptical about the cloud yet, then SAP offers you an on-premise alternative part of the SAP Process Orchestration - called SAP Business Process Management. Both solutions rely on an established notation - BPMN 2.0, so neither of them would be a bad choice at the end. Both are also quite flexible and easy to use when it comes to building workflows that communicate easily with third party systems. On top of that, they allow you to build very flexible and user-friendly self-service process that excels the standard SAP IdM self-serivce in so many ways (see screenshot (live example) at the end of the paragraph for an idea what is possible). The challenge when connecting to an external workflow solution is how to keep all the data consistent in SAP IdM and still have a proper audit trail. We can take that worry away by introducing our external workflow connector that takes care of all those technicalities and leaves you only the pleasure of using a flexible, easy to configure and mobile friendly workflow. A sneak-peek can be found below:
In general SAP IdM is designed to be a central system for connected systems, so it can control provisioning, de-provisioning and access granting in those systems. This is really great, but is it sufficient to have a 360 degree view on any access that any single employee has in your company. Definitely not! What is missing are all the little 3rd party systems, often ran only by some departments, or even the access cards opening the door to the office floor. If you add those to the picture, SAP IdM will become an invaluable system giving you one central entry point for anything that goes on in your company in terms of access. How can you achieve this? The answer is manual repositories. Definitely not something standard in SAP IdM, but easy to introduce with the proper preparation. Manual repositories do not provision your users, neither give or remove access for them. What they do is to orchestrate the important people for the particular system (e.g. the admin, the key user, the approver etc.) so that they are informed every time a new employee is hired, and certain access must be provisioned in the manual system, because it was part of the requested business role. The respective processor will receive a task and complete it only after the access has been granted in the target manual system. On the other side SAP IdM will update its access record and will show that the employee in question has access in the manual system. This is important, since during termination, it will also start a process for removal of that access closing the cycle in a neat way. Manual repositories work ok with the standard SAP IdM workflow, but their real potential is revealed only in combination with an external workflow solution (see previous chapter).
Notifications have been significantly revamped in SAP IdM 8.0 and now it is much easier to create and maintain them. Even though the user interface to do that is still Web Dynpro, this time this is not really a blocker, since mail templates are normally edited by administrators or IdM key users, who are not really that picky about the UI as long as it works. Here the blocker comes from the fact that properties within the emails are supported only from a limited number of entry types by default (e.g. MX_PERSON, MX_ROLE, MX_PRIVILEGE & CONTEXT). Additionally it is quite a challenging task, if you would like to check the contents and recipients of a sent email, where you were not in the delivery list. Standard notifications are also meant for one particular object of the above-mentioned entry types. Transport of notifications is also something that is not easy to achieve - especially in bulks. Wouldn't it be nice to have history of sent emails, an easy transport mechanism, a list of objects and any entry type you want sending the email in a nice CSS formatted envelope. One of our add-ons enables you to do exactly that. Setting it up is just a matter of configuration.
When it comes to external users, they are more like orphans to SAP IdM. No system would like to host them (e.g. to avoid licenses), but still companies want them integrated in the identity management cycle. No wonder why, after all most breaches and information leaks are expected to happen from external users and not your own. Therefore, having strict control over their lifecycle is essential. With so many implementation projects behind my back, I have seen as many interpretations of how external users can be handled. Some create them in Active Directory, other decide to load them directly in IdM with a certain identifier in place to differentiate them from internal employees. Although all approaches do the job, this has never been sufficient for us and we kept looking for the best possible solution. Our best practice proposes an external users' cockpit, which acts as an external HR repository to SAP IdM. It is the one stop shop when you have to deal with external users. You can hire, extend, lock/unlock, terminate, edit details - all in one Fiori user interface, providing you with comprehensive validations and access control (e.g. based on external company contract). This way you may be sure that you will never miss to extend your external project team and thus have zero disruptions in your on-going projects. Sneek-peak follows:
As with most enterprises the hiring process is long and exhausting. That is why, when an employee is finally hired, managers do not want to lose even a single day of his/her work schedule and would like to utilize him/her at full speed from day one. You might doubt if that is actually possible and you might be right – the person should fit in his new workplace, get to know his/her new colleagues, the work culture, etc. As much as this is true, there is also another side to it. Namely – the technical side, which asks the question – if all of the above conditions were met, would the employee be able to work at full speed from day one? SAP IdM has a goody in store, which might just solve that problem. It is called pending values. Pending values can be used with any attribute in SAP IdM and their purpose is to wait for a particular date and only on that date to apply a certain value to a certain attribute (e.g. some validity, a change in org. structure, etc.). Using pending values, a scenario like “Future hire” is very much possible. The scenario would lookup the date of hiring of the employee in question and start preparing his/her access upfront so that on the date of the actual hire, all the needed access can be already assigned, and the person would have his/her user/password pairs in the email waiting for first login. In theory the scenario seems perfect, if it wasn’t for one small, but very crucial detail. The above-mentioned pending values are being applied by SAP IdM in chunks in a random order and not grouped by MX_PERSON, which could lead to the case, where pending values for one person are not applied at once. A very strange behavior of the system is observed, especially when you rely on certain change triggers assigned to the attributes with pending values (which is something common).
Scheduling has been one of the highlights in IdM 7.2 offering fine grained engine rules that allowed you to schedule your jobs the way you want and at the exact time you want them to run. Unfortunately due to time constraints, the upgrade to version 8.0 neglected that part of the solution, but lucklily kept the database logic for it. This means that it is still all there, just a little bit hidden under the hood. SAP took a step forward to revealing the secret by releasing this SAP Note - > "2729037 - How to manually maintain scheduling rules in IDM 8.0". Now if you are really an SAP IdM expert, this note will give you a rough idea what you have to do, but since there are not many of these out there, we at ROIABLE decided to release an add-on to handle that and make it a gift to the community. Here is our sneak-peek preview:
Conclusion
As closing words to this rather long blog post I might say - Yes, SAP IdM is dead when it comes to version 7.2, the old provisioning framework, the old Web Dynpro user interface and the Microsoft Windows based console, but...
SAP IdM is very much alive, especially with version 8.0 SP06, the new extended support, the new/updated REST v2, the new Eclipse based console, the new provisioning framework, the hybrid connectivity and the numerous partner add-on offerings. So, what are you waiting for?
SAP Identity Management 8.0 plays an important role in both on-premise and hybrid scenarios for homogeneous and heterogeneous SAP/non-SAP landscapes
For those of you, who can't wait for the resolution of the title, feel free to skip to the end of the blog post, where the conclusion will reveal the mystery title. For everyone else, our journey will not start with the basics of what SAP IdM is and what the product is all about, rather I will list the most common functionalities of the product that are missing or not user-friendly to use and how you can overcome those on your way to a nearly-perfect identity management system.
- End user interface
First in the list comes the largely outdated end user interface of the product. Most (not all) of the SAP solutions have received their part of the Fiori pie and now shine in their new armor being more appealing, easy to use and mobile friendly. SAP IdM did an attempt to catch the wave already back in the 7.2 release, but apart from releasing a simple self-service static UI in SAPUI5, nothing else ever came to light. The reasons behind were multiple, but to focus on the two most important - incomplete and outdated REST v1 interface (at the time) and extremely complex dynamic generated Web Dynpro end user interfaces. This deadly combination pointed only in one direction -> SAP IdM won't have a Fiori end user interface anytime soon. However, thanks to the SAP Partner network, the above statement didn't really come true. Solutions to the problem started evolving - from simple to complex, from just showing the important information to the end users, to offering them comprehensive Fiori UIs streamlining their every day job. All those add-on solutions had one thing in common - they were re-creating the IdM UI the way partners saw it through their eyes. In fact, what the customers wanted was just the same logic they had in the past with Web Dynpro, but gaining the benefits of Fiori out-of-the-box. One of the many reasons for that was simple - migration! Many customers already have used SAP IdM for some years and dropping all their UI Forms configurations to start from scratch was not really an option. So was it possible to have it all - the flexibility of the IdM Forms with the benefits of SAP Fiori all in one dynamically generated UI. The answer is - YES! Here is a sneak-peek:
- Business roles management
Business roles were, are and will be an important functionality of SAP IdM. They allow customers to group privileges, based on certain person attribute values (keys), from different source systems into one common Role that symbolizes a certain job definition within the company - e.g. Accountant. The role for such position would ideally contain all privileges from all target systems, where an accountant will be active including SAP, non-SAP and even systems that are not directly connected to SAP IdM (more will follow in the next chapters - e.g. Manual repositories). The easiest way to maintain and upload such an access list using standard SAP IdM functionality is by loading a CSV formatted file in a job within the IdM Developer Studio or through the Web Dynpro user interface. As you are well aware both are not the most user-friendly interfaces, let alone assigning someone not familiar with the task to do it. From the real-world examples we have had in the past, I've rarely had a case where the responsible for that access list was someone who also knew SAP IdM in detail. A lot of questions start popping up:
- How would that person actually update the list without making a mistake?
- Who would actually make sure that the list is correct and there are no additional privileges assigned to the role that should not be there?
- Is there a way to know how many people will be affected from the access list without running it actually in the system (simulation)?
- What if the list is very long, but you just want to change one business role, do you have to upload the complete list?
Questions can continue, but let's focus on what can be achieved outside of the standard solution. Some of the functionalities are available if we add SAP GRC or SAP IAG to the landscape, but still those would cover only the SAP world, unless additional add-ons and/or connections are setup. The perfect solution would be one that provides a user-friendly interface to the person handling the access list with proper validations and feedback in place, easy roll-back options, versioning, delta functionality and context creation/assignment. Does it exist? The answer again is - YES! Below is a sneak-peak:
- Monitoring capabilities
When it comes to a running SAP IdM system, nothing is more important than making sure that this system is operational and functional at all times. Unfortunately, the standard means that SAP brings out of the box are not really the latest and greatest when it comes to that. The three main components that require monitoring are the tasks & jobs execution, the dispatchers' state and the processing queue. If any of these three gets stuck or overloaded, then nothing good is awaiting your SAP IdM system. Having an add-on that notifies you before things go wrong, might make the difference between a working and a non-working system. Adding the ability to start/stop your dispatchers remotely from one central place is a nice functionality that may spare you a lot of remote desktop connections in case you have multiple dispersed dispatchers running. Below is the sneak-peek:
- Mass changes
Mass changes have always been a burden in SAP IdM, not because they are complex to execute, but because they do mass operations in your system, which outcome is very hard to predict and once things start going the wrong way, it is very hard to say, which of your 100 changes didin't happen and why. The demand for more control, readable audit trail and proper user interface is growing with every new failed attempt for mass change. If the only thing you did so far was use a job with an uploaded CSV file attached to a complex script to do the job, forget about this extremely dangerous and un-friendly way of doing things. Say hello to a Fiori interface that guides you through the process, doesn't allow typos and writes every action you perform in a readable audit trail. Mass data changes, mass access updates, mass user lock/unlock - all included in a must have add-on for every SAP IdM implementation. Check out the sneak-peek below:
- Password Self-service
The default implementation of SAP IdM doesn't come with a self-service task for password change. However, to create one is rather simple. This simplicity, unfortunately, also brings certain restrictions. Probably the main one is that the user interface is still Web Dynpro (e.g. not mobile friendly). Another one is that the interface does not provide any feedback whatsoever as to whether the password has actually been changed in the target systems. This is standard SAP IdM behaviour, since IdM keeps only one central password, which is sent to all connected target systems. The process of changing the password in each system is a separate one and is not tracked by the user interface, so every time you change your password - the message would say - "Your password has been changed successfully." Nice, but not always true. There might be certain restrictions in the connected systems, which cannot be implemented within the SAP IdM password policy, because they do not apply to all systems - e.g. combination of certain characters might not be allowed, history of passwords might be different in the different systems, etc. The only way to overcome such obstacle is to have a separate status per connected system. This is what our add-on brings to the table - full transparency when it comes to password change/reset. You will always know if anything went wrong, change your password only in the systems you want and receive proper feedback when the change has actually happened in the target system. Follows the sneak-peek:
- Data and access integrity
In most SAP IdM implementations the identity management system is the central point of truth when it comes to user access and sometimes also to user master data (depending on the setup). It also happens that sometimes customers are sceptic as to how good SAP IdM can do its job and leave back-doors in the target systems, which allow users with sufficient privileges to modify master data or even access for users (e.g. in Active Directory). Those direct changes in the target system could be very harmful to how SAP IdM operates and should be avoided at all costs. A common way to solve such a challenge is to do a sync overnight from the connected systems and "inform" IdM about any changes that might have appeared. This approach, however, has one major flow - namely, was this access really added, because it was needed, or because someone wanted to gain advantage, which is otherwise not possible through SAP IdM (because of the approval process, SoD checks, etc.). Even if access changes are forbidden in the target systems, master data changes might be as well a great liability. A simple example is, if certain attribute value is changed and this particular attribute is responsible for a context assignment of privileges that give administrative rights. This would be a serious breach of security. While this phenomenon cannot be blocked or completely forbidden, it can be at least monitored and reacted properly upon. A friendly Fiori report can be available for every security admin to check at any time and react adequately to changes performed in the target systems (e.g. accept them or overwrite them with the data in IdM). The sneak-peek:
- Connectivity
Connectivity has always been one of the strong sides of SAP IdM. Offering a number of standard connectors for SAP and non-SAP systems, the selection is further enhanced by the large partner network. On top in IdM 8.0 SP06 hybrid connectivity with the SAP Cloud Security services was introduced, which opened a whole new world of possibilities. The implementation of a custom connector to a system that is not supported out-of-the-box by SAP IdM is not a rocket science task for experienced consultants, but if you have to scale that to a multitude of systems with different interfaces, things might get a bit out of hand. The problem solver in this case might be a generic web service connector that can adapt to any SOAP interface from the target system and connect it easily in the SAP IdM process. Using the add-on, connecting target systems that support SOAP connectivity becomes an easy and repetitive task.
- Workflow
Workflow capabilities have been drastically improved in the SAP IdM 8.0 release, but they are running behind when compared to the other SAP workflow technologies like SAP BPM or SAP Cloud Workflow. While SAP IdM workflow is completely sufficient for simple approval flows and processes that stay inside the SAP IdM context, things start to reach the limits of the solution, when we have to connect an external system - e.g. a rules framework to check some conditions. SAP IdM workflow is quite limited when it comes to that. Also, if you have to build a rather complex process with returns to previous steps, error handling, notifications, SLAs, intermediate message events, etc., then you definitely need to think about an alternative. If you are already cloud minded, then you might consider the SAP Cloud Workflow. However, if you are feeling a bit skeptical about the cloud yet, then SAP offers you an on-premise alternative part of the SAP Process Orchestration - called SAP Business Process Management. Both solutions rely on an established notation - BPMN 2.0, so neither of them would be a bad choice at the end. Both are also quite flexible and easy to use when it comes to building workflows that communicate easily with third party systems. On top of that, they allow you to build very flexible and user-friendly self-service process that excels the standard SAP IdM self-serivce in so many ways (see screenshot (live example) at the end of the paragraph for an idea what is possible). The challenge when connecting to an external workflow solution is how to keep all the data consistent in SAP IdM and still have a proper audit trail. We can take that worry away by introducing our external workflow connector that takes care of all those technicalities and leaves you only the pleasure of using a flexible, easy to configure and mobile friendly workflow. A sneak-peek can be found below:
- Manual repositories
In general SAP IdM is designed to be a central system for connected systems, so it can control provisioning, de-provisioning and access granting in those systems. This is really great, but is it sufficient to have a 360 degree view on any access that any single employee has in your company. Definitely not! What is missing are all the little 3rd party systems, often ran only by some departments, or even the access cards opening the door to the office floor. If you add those to the picture, SAP IdM will become an invaluable system giving you one central entry point for anything that goes on in your company in terms of access. How can you achieve this? The answer is manual repositories. Definitely not something standard in SAP IdM, but easy to introduce with the proper preparation. Manual repositories do not provision your users, neither give or remove access for them. What they do is to orchestrate the important people for the particular system (e.g. the admin, the key user, the approver etc.) so that they are informed every time a new employee is hired, and certain access must be provisioned in the manual system, because it was part of the requested business role. The respective processor will receive a task and complete it only after the access has been granted in the target manual system. On the other side SAP IdM will update its access record and will show that the employee in question has access in the manual system. This is important, since during termination, it will also start a process for removal of that access closing the cycle in a neat way. Manual repositories work ok with the standard SAP IdM workflow, but their real potential is revealed only in combination with an external workflow solution (see previous chapter).
- Notifications
Notifications have been significantly revamped in SAP IdM 8.0 and now it is much easier to create and maintain them. Even though the user interface to do that is still Web Dynpro, this time this is not really a blocker, since mail templates are normally edited by administrators or IdM key users, who are not really that picky about the UI as long as it works. Here the blocker comes from the fact that properties within the emails are supported only from a limited number of entry types by default (e.g. MX_PERSON, MX_ROLE, MX_PRIVILEGE & CONTEXT). Additionally it is quite a challenging task, if you would like to check the contents and recipients of a sent email, where you were not in the delivery list. Standard notifications are also meant for one particular object of the above-mentioned entry types. Transport of notifications is also something that is not easy to achieve - especially in bulks. Wouldn't it be nice to have history of sent emails, an easy transport mechanism, a list of objects and any entry type you want sending the email in a nice CSS formatted envelope. One of our add-ons enables you to do exactly that. Setting it up is just a matter of configuration.
- External users
When it comes to external users, they are more like orphans to SAP IdM. No system would like to host them (e.g. to avoid licenses), but still companies want them integrated in the identity management cycle. No wonder why, after all most breaches and information leaks are expected to happen from external users and not your own. Therefore, having strict control over their lifecycle is essential. With so many implementation projects behind my back, I have seen as many interpretations of how external users can be handled. Some create them in Active Directory, other decide to load them directly in IdM with a certain identifier in place to differentiate them from internal employees. Although all approaches do the job, this has never been sufficient for us and we kept looking for the best possible solution. Our best practice proposes an external users' cockpit, which acts as an external HR repository to SAP IdM. It is the one stop shop when you have to deal with external users. You can hire, extend, lock/unlock, terminate, edit details - all in one Fiori user interface, providing you with comprehensive validations and access control (e.g. based on external company contract). This way you may be sure that you will never miss to extend your external project team and thus have zero disruptions in your on-going projects. Sneek-peak follows:
- Future values
As with most enterprises the hiring process is long and exhausting. That is why, when an employee is finally hired, managers do not want to lose even a single day of his/her work schedule and would like to utilize him/her at full speed from day one. You might doubt if that is actually possible and you might be right – the person should fit in his new workplace, get to know his/her new colleagues, the work culture, etc. As much as this is true, there is also another side to it. Namely – the technical side, which asks the question – if all of the above conditions were met, would the employee be able to work at full speed from day one? SAP IdM has a goody in store, which might just solve that problem. It is called pending values. Pending values can be used with any attribute in SAP IdM and their purpose is to wait for a particular date and only on that date to apply a certain value to a certain attribute (e.g. some validity, a change in org. structure, etc.). Using pending values, a scenario like “Future hire” is very much possible. The scenario would lookup the date of hiring of the employee in question and start preparing his/her access upfront so that on the date of the actual hire, all the needed access can be already assigned, and the person would have his/her user/password pairs in the email waiting for first login. In theory the scenario seems perfect, if it wasn’t for one small, but very crucial detail. The above-mentioned pending values are being applied by SAP IdM in chunks in a random order and not grouped by MX_PERSON, which could lead to the case, where pending values for one person are not applied at once. A very strange behavior of the system is observed, especially when you rely on certain change triggers assigned to the attributes with pending values (which is something common).
- Scheduling
Scheduling has been one of the highlights in IdM 7.2 offering fine grained engine rules that allowed you to schedule your jobs the way you want and at the exact time you want them to run. Unfortunately due to time constraints, the upgrade to version 8.0 neglected that part of the solution, but lucklily kept the database logic for it. This means that it is still all there, just a little bit hidden under the hood. SAP took a step forward to revealing the secret by releasing this SAP Note - > "2729037 - How to manually maintain scheduling rules in IDM 8.0". Now if you are really an SAP IdM expert, this note will give you a rough idea what you have to do, but since there are not many of these out there, we at ROIABLE decided to release an add-on to handle that and make it a gift to the community. Here is our sneak-peek preview:
Conclusion
As closing words to this rather long blog post I might say - Yes, SAP IdM is dead when it comes to version 7.2, the old provisioning framework, the old Web Dynpro user interface and the Microsoft Windows based console, but...
SAP IdM is very much alive, especially with version 8.0 SP06, the new extended support, the new/updated REST v2, the new Eclipse based console, the new provisioning framework, the hybrid connectivity and the numerous partner add-on offerings. So, what are you waiting for?
- SAP Managed Tags:
2 Comments
