The topic of Single Sign-On (SSO) has come up recently with…
If you’re reading this, you probably already know Oracle’s Identity Governance products help simplify and reduce the costs of provisioning, attestation, compliance and segregation of duties. What you may not know is that Zirous has worked with these products for 5 years. We’ve implemented a variety of solutions for clients in industries ranging from banking to government to higher education. Even across a variety of industries, we’ve found that our clients have common business issues to address and common implementation pitfalls to avoid. Today, I’m going to discuss three of those potential pitfalls that may arise during an Oracle Identity Manager (OIM) 11g implementation.
Choose your Customization Wisely
As you know, OIM is highly customizable. There are a large number of defined extension points that allow you to add custom request validation, event handling during provisioning, basic (and advanced) UI customization, and much more. Oracle has done a nice job of providing a way to add user-defined fields to common objects, such as the User and Catalog, with minimal effort.
The unspoken truth of customization is that, while you get what you want, it comes at the cost of additional maintenance. Some kinds of customization are easy to maintain. If standard extension points are used, the maintenance effort is minimized and the changes do not have to be re-applied during patches and are less likely to be affected by changes in general system functionality. But not all customizations are quickly and easily implemented. Some are very complex and are intended to alter fundamental OIM processes. These are more likely to be affected by changes in OIM functionality and the business drivers for these kinds of customizations should be weighed against the risks and effort of ongoing maintenance. Several of our clients have commented that after implementing highly customized solutions, they have a desire to change their business processes to align with out-of-the-box functionality. They found that the drawbacks of maintaining a customized solution were more than they wanted to take on. Because of this, Zirous recommends that companies fully understand the risks and benefits before committing to a deeply customized solution.
RBAC and the Three Bears
Take a tip from Goldilocks. Role Based Access Control (RBAC) is best implemented when the number of roles is “just right”. Too many roles, and you’ll incur a maintenance headache while simultaneously making it more difficult for your users to find the correct access. If you have too few or none, it’s more difficult for users to make requests, perform certification and standardize access. If you do pursue RBAC, don’t assume everything needs to be squeezed into a role. Some access should be requested via one-off entitlements, and that’s ok.
Don’t try to make roles encompass too many or too few entitlements. If you find that you’re often associating one entitlement to one role through access policies, then re-examine your approach. Making access policies that are too broad (the “kitchen sink” access policy) is just as bad and you may end up granting unnecessary access. Role mining and properly setting up roles and access policies is a time consuming process. Make sure your project allows enough time so that the approach is just right.
Often, clients want to implement provisioning, RBAC and other governance tasks to all systems at once in order to provide a fully-functional, one-stop-shop solution to users. This can often bog down a project and extend its duration making it difficult to see the benefits. Zirous believes it is beneficial to perform pilot projects first, especially when a provisioning tool is new to an organization. Understand how the tool works and how your company’s users utilize it on a smaller scale so the team can take that experience and apply it to provisioning a wider array of systems. This approach will also help get some quick results that will allow everyone, from end users to executives, to see the benefits of OIM.
Your Mileage May Vary…
Every implementation is different. The suggestions presented here are general guidance that will work in many situations, but not all. An experienced implementer like Zirous can understand how your business needs can be addressed while avoiding common pitfalls.
If you have questions about the OIM product, or other tools in Oracle’s Identity product set, let us know in the comments.
Also, be sure to follow me on Twitter, @zirous_dcline