CHAPTER 19
Post-Implementation: Keeping the Framework Running
Great works are performed not by strength but by perseverance.
—Samuel Johnson
At last, you’re done. It’s up, it’s functioning. Your IAM framework creates new user accounts, provisions those users, governs their access, and keeps all this activity secure and compliant. There’s nothing left to do! Except, you know, the really, really hard stuff.
With the framework operational, expectations will be higher than ever. Those who gave you budget and resources are certainly awaiting results from their investment; auditors are anticipating transparent, comprehensive data; and the employees, customers, and partners who are supposed to see enhanced security, service, and privacy should be instantly benefiting from a better user experience.
If evolution is the process by which species adapt to changing circumstances and environment, then consider the evolution of your organization as your identity and access management framework takes root and begins to influence your own environment, hopefully for the better. As your situation progresses, you will need to keep certain processes progressing as well.
Adoption
Remember what I said about how you need to keep selling? Well, if you ever want more budget for another project, or even just a second round for the next phase of the current project, make sure that information about the benefits of what you’ve done so far gets sent up the chain, although subtly and humbly.
“You mean you want to add strong authentication now? Heck, nobody’s even using the provisioning tool yet, they’re all still fat-fingering people into LDAP.”
This means getting people to use the thing. If it’s all been planned correctly, and sold internally, then the stakeholders and users should see the benefits of participating. It’s meant to make their lives easier. It’s likely a mandate. You’d like to think that your kids love you because, well, because they love you, and not just because you’re the family wallet. And you’d like your internal customers to use the new IAM system because they love it, not because they must. On the access management side, they really have no choice, since they’re getting prompted and policed and audited by the tools no matter what. Ask the web server for a page, pass through the WebGate for authorization. But unless you’ve got all the provisioning automated, they might still be pounding their own new users into the database and bypassing the requests and approvals. Even if they’re following policy, they’re not feeding the audit data.
If you need a hammer, remember the big one, compliance. Everyone should be getting enabled, re-enabled, and disabled via the proper protocols, not under the desk or behind the curtain. The second big one is likely security. This by itself serves the purpose of compliance. And then there’s automation. This is a cost-savings and time-savings endeavor. There may be other drivers as well. Regardless, you have made the investment for very good reasons, and you need people to use it, for those same very good reasons.
In the meantime, while you’re pushing that adoption, remember that there’s a difference between implementing and rolling out. But let’s revisit it briefly.
Implementing is installing, integrating, launching.
Rolling out is getting your users and administrators on board with the operation. You may or may not have been involving the users in the deployment, but before you throw the switch, it’ll be time to get them plugged in, to avoid culture shock, and to make them and the IAM platform as productive as possible, as quickly as possible. This is where your education initiatives come in, including training and informational web site or e-mail blasts or whatever means you use to let people know when it’s coming, when it’s here, and where it’s going. As you’re implementing, you should be explaining to the community that the project is underway, that the benefits will be a positive thing for all, and there will be some differences.
Show Results
As we’ve already discussed, for the sake of keeping the confidence of stakeholders and/or management, keeping the funding coming, keeping the end-user community focused, and to ensure that everyone stays committed to adoption, it is highly recommended to show early results. These cannot be accidental; as I keep repeating, you should set an advance target, such as simple authentication and authorization, self-service, or provisioning to basics such as e-mail or the corporate LDAP. These early targets should either address the needs of critical stakeholders or the most users possible (or both). Any kind of automation is always something to show off, since manual processes are de rigueur, and taking those off the table is not only an obvious benefit; it’s just plain obvious.
Monitor Those First Transactions
The first cycles are immensely important. Undoubtedly you’ll be tuning policies, performance, notifications, and any number of other factors early on. That is not to say that everything will break. But even things that are working will perhaps not work quite the way you expected.
I remember an admin telling me how, shortly after his new identity system was operating, he was surprised by how many automated e-mails he started getting, and he made a couple of adjustments to alert levels and mailing lists.
The purpose of the IAM framework is to support compliance, security, and automation. If things aren’t running a whole lot faster and safer, then you might need to do some tweaking.
The reporting engine across the Oracle identity suite is BI Publisher. It preserves and builds on the reports that have always been available through the individual components. These reports consist of both operational and historical data. These reports are not only useful for audit support purposes; they also help in analyzing usage and activity. By examining elements such as requests, approvals, password reset successes and failures, and other activities, you can identify areas where adjustments may need to be made. For example, the most basic of resources, such as access to e-mail, are most often granted automatically upon registration. But I have seen cases where literally every access point was subject to approval, which seems a burdensome bottleneck. Of course, I have also seen the exact opposite (often in higher education), where access to nearly every resource is automatic, while de-provisioning is not, resulting in far too much access for far too many people without benefit of review.
Pass That Audit
Many times I’ve started solution cycles with customers, from the point of exploration all the way through to choosing software and consulting resources, because of compliance concerns (either a failed audit or upcoming auditing requirements). If you’ve specifically failed an audit, then it’s fairly simple to determine the exact requirements. But if it’s a compliance mandate that you haven’t faced previously, then you design your approach as best you can and, no kidding, hope that it’s enough. Unless you’ve got internal and/or friendly auditors guiding you at every step, providing a very detailed blueprint, you can never be sure until the time comes that you’re going to be judged compliant. In the last few years, audits have gone from fairly predictable events to learning experiences. Such is the nature of our new world.
If auditors are going to personally review your user-privilege data, then there are two ways you can go about making sure users have least privilege. The first is having reconciliation run between Oracle Identity Manager and the target systems. However, this is probably an unlikely short-term solution to your audit needs, for two simple reasons: Early in the project, you probably don’t have all source and target systems hooked up to your framework, and even if you did, you probably haven’t had time to tighten up all access policies. Either way, within the first few weeks it’s highly unlikely that the new framework governs access to all the legacy systems.
The second option, attestation (or certification), is far more likely to succeed for you than reconciliation for that first audit. For one thing, you can generate attestation reports even for resources that are not fully integrated for provisioning (although any resources not integrated will not benefit from actionable attestation). Attestation gives you concrete, detailed evidence of a critical and very common compliance process being performed. It’s easier for auditors to process this kind of information, since a majority of the time they won’t be combing your user-privilege data at a granular level. As we discussed a little earlier, a chunk of compliance is simply the requirement to demonstrate that you’re compliant, so hard copy always scores you points.
Accountability
Besides basic deliverables, make sure that all parties are sticking to their duties. When you have two or more integrators in play, you will absolutely need to monitor and smooth out communications between them, if you are not overtly controlling all traffic. I have multiple times seen a major integrator in charge of architecture and project management, while another integrator provided most of the heavy lifting. Most of the time they get along, but there’s always some degree of jockeying for position.
Monitor, Maintain, Modify
The one constant in life is change. It’s not always for the best, but you can’t stop it. Once you have your framework up and running, you will have a window during which you will mostly just let it be. And then you will have no choice but to change anyway. On the administrative side, some activities will require more effort and attention than expected, while others will take less.
On the user side, some people will resent new requirements, and some people will use the system in ways you neither want nor expect. You must realize, that’s always been going on, only now you have better facility to detect and mitigate the situation.
Workflow definitions that route approval requests may be shortened. You may also be adding approval stops as well. Authorization rules sometimes get tweaked to make them more, or less, restrictive.
Once you’ve got your identity framework in place and working relatively well (after all those initial tweaks), it’s time to see if it is actually being used the way you thought it might. You have dashboards and reports (which we’ve talked about) that allow you to look at the trends and the options:
The most active users
The least active users
The average session length
How long it takes for a user to be fully provisioned
Which resources get the most use
How well are assigned tasks (for example, certification) being executed
What you can do with that data to make things run even more smoothly
Monitor and Manage the Pieces
Enterprise solutions are never simple, in terms either of their functionality or their architecture. You need to be able to check the temperature of your framework as needed, to ensure it is operating correctly and will continue to do so. Occasional adjustments may be necessary. And even without taking adjustments into consideration, you have distributed components that defy easy management just because of volume and location.
Oracle Enterprise Manager/Grid Control provides a framework (remember that all-important word?) for monitoring and configuring Oracle product components. Like an IAM framework, it provides for additional functionality to be plugged in, in this case in the form of what Oracle calls Management Packs. Packs are available for the range of Oracle products, including identity, federation, and access servers. Management Agents can actually perform discovery on the IAM components to bring them under the management umbrella. Once discovered, these components can all be analyzed individually.
Oracle Enterprise Manager provides a real-time dashboard for monitoring the health of your identity services. It can simulate user access and measure the responsiveness of the components. From a comprehensive console, you can centrally manage your framework, including Oracle and non-Oracle components such as firewalls, app servers, and directories. Enterprise Manager facilitates the discovery of new systems, automates the management of component configurations, and aids in the diagnosis of system faults.
OEM essentially provides a home page for every piece it monitors. If you are monitoring a service with subcomponents, then that service’s home page within EM also provides links to the home pages for those components. On the home page for a service, EM displays the following information:
Server status and performance
Alerts
Issue isolation data for diagnosis and resolution
Resource usage
Policy violations and their severity
Links for starting and stopping components
Server configuration data
By having this kind of data at your fingertips, you can make critical decisions on changes to your framework, including policies, sizing-up, load balancing, and other adjustments that can affect not only performance but security. As of this writing, I watched an engineer, just a week ago, use OEM to hunt down the bottleneck in a reconciliation process during a proof of concept. He diagnosed the problem and determined the solution, by using Enterprise Manager.
OAAM and the Evolution of Policies
Recall that Oracle Adaptive Access Manager provides a dashboard for monitoring possible real-time fraudulent activity. It can help analyze performance, statistics, risk scoring, and devices. You can also use the dashboard to create proactive fraud prevention rules by identifying suspicious activity.
You will have already established a baseline for what is considered acceptable user behavior, but now you will begin analyzing ongoing user activity, including any alerts that may have been generated. This allows you to refine risk profiles. Just to reiterate what has been previously discussed: A risk score is a combination of factors that include not just who you are (or who you purport to be) but also what you are, where you come from, how you act, and when you act.
OAAM is already aggregating historical data on users, which allows it to recognize anomalous behavior and react accordingly by, for example, performing denials or notifications based on activity that is out of the norm. But as an administrator, you help OAAM to do its job by adjusting that baseline.
In Chapter 10, we discussed using Oracle Adaptive Access Manager to create patterns or buckets of behavior (with established memberships) against which OAAM matches user activity, in order to find anomalous behavior. In other words, if members of a bucket aren’t acting in a way you expected or care to allow, OAAM can identify those activities and adjust memberships accordingly via auto-learning.
For example, let’s say you originally set up a pattern that includes the employees who work out of a particular office. Those employees who authenticate from that office are prompted for name and password. Whenever one of those employees authenticates from a different office, they are prompted for an additional PIN. You may also set up a threshold within the pattern that says, if an employee doesn’t authenticate from that office within 30 days, he is automatically pulled out of that bucket, and his authentication requirements change accordingly, and permanently.
It’s advisable for administrators to periodically review reports on bucket memberships, usage, and statistics, to determine if there is a need to adjust the requirements. For example, an office that includes a lot of salespeople who spend most of their time traveling might experience a large membership change, in which case the need for a PIN might be coming up more than you’d like.
Because one of the functions of OAAM is fraud prevention, it also provides the ability to open and track agent (fraud) cases. A regular customer service case can be escalated into an agent case (although the reverse is not true). Cases allow investigators to examine user sessions and any pertinent alerts. Sessions can be linked to a case, along with an accompanying importance level. If a suspicious user session automatically creates a case, then that session is automatically linked to that case. Specific data elements can also be linked to a case. Linking sessions and data to cases empowers investigators to focus on only the most relevant information in determining actual fraud.
In customer service cases, there is an option to unregister all devices for a user, forcing that user to perform activity from a standard device. Again, things change.
Deploying the Next Phase
You may recall the advice not to boil the ocean, and to deploy in phases. That means deferring some requirements until later. Well, now it’s later. You’ve got that initial deployment online, so it’s time to start considering the next phase. You’ve got more users to bring on board, more roles to construct, more resources to provision, and therefore more workflows to define and more access policies to establish. Make use of your log of what you’ve learned, what’s worked and what hasn’t, to refine your procedures for a smoother next phase, which should go faster and with fewer obstacles.
Did you run into issues getting service accounts created? Ports through the firewall? Hardware? Approvers doing their approvals? Do you need someone in management to apply any pressure? Do you need to put in your requests for accounts, ports, hardware, or pressure with more lead time?
Standards Support
Does anybody remember Security Services Markup Language (S2ML)? It morphed into Security Assertion Markup Language (SAML), which people used to laugh at because of the name. I worked at a company whose engineering department had practically invented SAML, and yet one year at a huge industry show in San Francisco, we were the only vendor in our space not demonstrating a product that supported it. It was embarrassing. SAML finally took off in a big way, and it’s completely legitimate to ask if a product supports it. In fact, it’s a necessity.
Some “standards” are simply trial balloons that are floating around out there, or good ideas that may or may not be validated eventually by the market. That’s not to say that ideas necessarily need validation by commercial ventures, but without such support, they don’t get far, and they get most of their attention on West Coast university blogs. Eventually some of them build up enough demand to weigh them down and bring them to earth, where they are adopted. And some just keep floating around, or die altogether. I’ll bet you’ve never heard of S-HTTP (not to be confused with HTTPS).
A couple of years back, I was asked point-blank my unvarnished opinion of Service Provisioning Markup Language (SPML). A customer was looking at a couple of other add-ons, and was talking to vendors who didn’t support SPML. I pointed out two things. Everybody was talking about SPML, but at the time, hardly anybody supported it; and eventually, whatever products they purchased would surely support it, if the market demand was there. Oracle Identity Manager supports SPML because customers demanded it, and it was an obvious roadmap item anyway. When you install Oracle Identity Manager, it generates a file for running the SPML Web Service, which turns SPML calls into provisioning calls.
However, SPML just isn’t being adopted at the rate everyone assumed. Those relatively few vendors who have assimilated it often find themselves customizing their implementations. The standard itself, as of this writing, is too complex and does not perform well. The lack of a standard user schema doesn’t help either, and that by itself will be difficult for all parties to agree on.
Client Attribute Request Markup Language (CARML) and Attribute Authority Policy Markup Language (AAPML) are on the way, but they could still be a long way off from full adoption. CARML defines privacy and attribute requirements for an application. It’s like WSDL for non-services. AAPML defines when specified data elements (usually identity-related) are made available to applications, and how these elements can be used. I can edit my own home address and phone number, but am I allowed to edit my account number? Will I allow any of my elements to be used by another application for contact or other purposes? The reason someone thought these up is that while identity components have been mapped to use certain identity data, there was no way to describe the purpose of that data, and the rules for using it. Now, you could say that the people who make use of that data in the first place, for provisioning, authentication, authorization, and so on, already know what they need and why they need it. But as the world becomes more interconnected, and cloud computing becomes more the norm (with our data flying all over the place), we might want to package it up in such a way that it says to anybody looking at it, “Here’s my data… and here are the rules for using it.”
CARML and AAPML are layers of the Identity Governance Framework (IGF), which was created by Oracle to help companies specify how to use, store, and communicate identity information. IGF is now hosted by the Liberty Alliance.
Meanwhile, Extensible Access Control Markup Language (XACML) describes who has access to which resources. Not only is it a useful introduction for a user to a system (“Here’s what he can have”), it is also a great way to store policies.
It would be nice to say that one day there will be a unified standard for Web service security, but not in our lifetimes, and that’s not for technical reasons.
Why do you care about standards?
Federation Your next big business partner may require that you support what they support.
Compatibility Integration with your next corporate business app may require that you support its favorite protocol for provisioning or synchronization.
Quicker integration My API doesn’t like your API? Darn. But hey, we both speak the same standard, so let’s communicate that way instead.
Who would have suspected, just a couple of years ago, that social networking functions, mashups, instant messaging, and wikis would become accepted, and even vital, business supports?
I occasionally (as in rarely) hear of Directory Service Markup Language (DSML). This is LDAP translated for HTTP traffic so that you don’t need an LDAP client. It enables your browser to deal with LDAP, as well as package up multiple LDAP operations into one request. Does your IAM package need to support DSML? Not immediately, although Oracle Virtual Directory does.
So if all of this sounds so intimidating and complicated, what is the happy thought we take away from this? That’s easy. If you deploy your business applications behind an identity and security framework, you have insulated those apps from those changes. Communications from the outside to those business apps can be mitigated by the framework, which intercepts resource requests, and subsequently communicates to those apps only the information that they need to know in order to allow in the user whom the framework has just authenticated and authorized. Here’s the session ticket, here’s the token, here’s the assertion; please let him in, and don’t worry about how it was done.
An IAM framework can not only be configured to support particular standards (most often in regard to communications with source and target systems), but it can actually facilitate the rollout of new standards. Here’s my main point: Having a separate security layer, in the form of that framework, insulates business apps from having to deal with the baggage of those standards. This means that when new standards or protocols are deployed, the actual linkage is made with IAM, lessening the impact on the business itself.
What Did We Learn From All of This?
The effort to scope, lobby for, design, build, and deploy an IAM framework is more than considerable. It’s a lot of very hard work, and requires considerable cooperation and contributions from many parties. The sheer improbability of success makes that success such an achievement.
The information and experiences I’ve related in this book probably seem like just common sense to many folks. There are likely things in this book you’d long thought of, heard of, suspected, seen done, or at least attempted. But hopefully you’ve learned a few new things, and if nothing else you’ve probably found a few things to be afraid of. Fear is a good thing, because it compels you to avoid bad choices, either yours or someone else’s.
I always tell my kids, no matter what vocation they pursue in the future, even if it’s in liberal arts, it will require (1) using a computer and (2) having good communication skills. Well, no matter what enterprise applications or systems you use or deploy, they will require identity, access, security, and compliance. These are as inescapable as they are necessary. By designing in consideration of these requirements, instead of treating them like an afterthought, you are going beyond providing functionality, and presenting great benefit and value to your organization.
After you’ve done one (or more) of these IAM projects, your brain will be that much bigger. This is one of the most critical things an organization can do, getting a handle on who’s doing what and when, by using technology and standards that continue to evolve, and hopefully you’re the one who got them started. Not only can you say you’ve secured an organization’s most private, important, and sensitive data, helped them protect their assets from people with bad intentions, and provided a great service for end users, you’ve also benefited personally by way of what you’ve learned. If you’ve used the Oracle security suite, you will have (at least partially) mastered a solution that the analysts call the leader in provisioning and access management. Regardless of your chosen toolset, you’ve gained a lot of knowledge along the way
Just think of your resumé. It will contain your title, tags, and historical data, including your most recent accomplishment, “Designed and implemented Identity and Access Management at MegaBigCorp.” And right above that item will be your name, address, and e-mail. This entire combination will consist of who you are, and what you are; in other words, your fully qualified identity. It’s how someone will contact you when they need to speak with someone who, having lived through the long, difficult, and educational process of building an IAM framework, can now reasonably be called an identity and access management expert.