Best Practice IAM Projects

While most of our articles are technical in nature, this week we wanted to look at identity and access management (IAM) from a higher level perspective. Why? Because while knowing what button to push and which knob to turn is important, those things don’t guarantee success for a project. So what does? Nothing! But following best practices, while turning the right knobs, will give your project its best chance for success.

Best practices can vary based on a number of factors, but we have tried diligently to distill our list down to the things that are most critical to IAM project success. For the sake of brevity, we will only cover ten items in this list, but we have a SiteMinder 12.8 book in the works that will include our complete list and be available soon.

1. Gather a good set of requirements. Depending on the size and complexity of an IAM project, collecting the relevant requirements could be as little as reading a document or as much as hosting a series of meetings with interested stakeholders. While customers will typically drive how you receive the information, the data required tends to remain relatively the same and can be summarized in a reusable template.
2. Carefully manage the scope. If you have done a project, you have experienced scope creep. Resisting the urge, or client requests, to do more than was specified in the requirements and design documents is critical to project success. Also, you can prevent project failure by using a multi-phased approach while limiting the scope and complexity of the initial phase to get a quick win.
3. Clearly define and communicate dependencies. Both technical and personnel dependencies can be overlooked and projects suffer because of it. IAM systems, with the policy decision point typically on the application tier, rely on a variety of products on various tiers and can be blamed for authentication issues that originate from other components like web and database servers.
4. Do a proof of concept (POC) project. Sales pitches can vary in the amount of exaggeration or embellishment that people are willing to use to make a sale, so it is wise to perform a proof of concept project to verify that the IAM product can truly fulfill your requirements. Make sure that your internal IAM personnel are involved so that you can reasonably verify the POC results (and gain some knowledge transfer at the same time).
5. Make sure that your POC is effective. While it seems redundant with the previous best practice, this recommendation focuses on making a useful selection of requirements to examine during the POC. Since scope can be an issue in this area also, our general recommendation is to select three use cases to demonstrate: one easy, one of medium difficulty, and one of critical importance that usually will also be the hardest of all the requirements.
6. Use multiple environments. In the early days of identity and access management, many organizations would use one instance of their IAM product to develop, test, and run their system. Taking cues from the software development folks, the best practice has evolved to use a minimum of development, test, and production environments, with some organizations adding a pre-prod environment to replicate and resolve production issues.
7. Know who will own the system. To prevent a game of ‘IAM hot potato’ from breaking out once the system is deployed, it should be clear which group and set of personnel will own the IAM system. Whether going to the security group or an IT department, the personnel should receive the proper training and have an opportunity to participate in system deployment before it lands in their lap for good.
8. Have an enterprise architect. If this list was ordered by the importance of a best practice, this recommendation could very well be number one. Even if only in a reviewer role, an enterprise architect will be able to see across interfaces and at a higher (enterprise) level where many IAM system problems tend to crop up.
9. Complete your documentation. Not many technical people enjoy doing it, but documentation is very important for IAM systems and must not be neglected. From capturing critical decisions made during requirements and design to establishing how testing will be done, IAM documentation will serve as historical record, planning documents, and operational manuals for the life of the system.
10. Monitor your system. Even in the absence of governmental requirements and technical performance concerns, system monitoring is instrumental in maintaining customer satisfaction. System issues are inevitable, but with well implemented monitoring they can be caught and remedied prior to customers, or organizational superiors, finding out about them.

As mentioned above, we are excited about our new book that should be available soon. If you haven’t already, please join our mailing list and keep an eye out for the book and more IAM articles. If there are any topics that you would like us to discuss in future articles or if you need IAM consulting help, feel free to send us an email at info@secidsol.com.