The popularity of entitlements, both as a noun and as a thing, is rapidly growing in the IDM world. Before entitlements became an oratorio impossible to ignore even with the best Jedi mind tricks, there was a flutter of butterfly wings. That is, 2-3 people in a hallway at a conference started whispering entitlements,entitlements,entitlements . Then came presentations, then whitepapers from analysts and vendors and finally the Market noticed that, wait, what about entitlements? The chaos theory refers to the initial whisper event as a butterfly effect, there's no other explanation for their sudden rise to fame. I mean, it's not like they didn't exist, they were just invisible to the human..err...auditors' eye. Hail Eris!
Much to the delight of those semantically inclined, the definition of the noun entitlement has proved hard to nail down in the identity and access management context. While we were feeling smug and entitled, we've written a blog post on the subject along with a whitepaper (registration required) that talked about the challenges of managing entitlements throughout their lifecycle. Let's see some popular definitions of entitlements:
by Deborah Volk on Tuesday September 15, 2009
no comments
- Webster / Wikipedia: A right to benefits, esp. by law or contract
- Burton: Object in system’s security model that can be granted or associated with a user account to enable the account to perform (or prevent performance of) a set of actions on the target system
- BEA (now Oracle!): Set of privileges that govern what an application user can do
- Identigral: A business rule expressing actions that can be allowed or denied
From our perspective, it doesn't really matter that the entitlement is granted to an account, a user, an application (yes, applications have entitlements too!) or some combination thereof. The act of granting and the subsequent association between an entitlement and its subject (owner) is not relevant to the definition of entitlement. Webster is closest to what we feel is the best definition. Let's consider an example somewhat divorced from technology.
In a mythical company Ourbont (pronounced oooor-BON, yes it's French) there are monthly management meetings. Everyone who manages other people is invited to the management meeting. The security guard at the door personally knows the managers (it's a small company) and on the basis of, well, your persona, does or does not let you into the meeting. You could say that being a people's manager is an entitlement. It was something that was made into 'law' by the contract between the employee and the company at the time of hire. You could also say that being able to attend management meetings is an entitlement, perhaps a derived one, since it follows from one being a people's manager. The latter entitlement exists due to company policy which (loosely speaking) is a form of law/contract.
In a mythical company Ourbont (pronounced oooor-BON, yes it's French) there are monthly management meetings. Everyone who manages other people is invited to the management meeting. The security guard at the door personally knows the managers (it's a small company) and on the basis of, well, your persona, does or does not let you into the meeting. You could say that being a people's manager is an entitlement. It was something that was made into 'law' by the contract between the employee and the company at the time of hire. You could also say that being able to attend management meetings is an entitlement, perhaps a derived one, since it follows from one being a people's manager. The latter entitlement exists due to company policy which (loosely speaking) is a form of law/contract.
We continue to believe that enforcing access based on entitlements is a relatively understood issue. Sure, there are implementation challenges but there's an embarassment of riches when it comes to picking products that enforce access. In the Oracle IAM stack alone, you can throw a dart at the wall and hit a product that can check entitlements and allow or deny access:
Oracle Access Manager (OAM) - authorization rules in a policy domain.
Oracle Virtual Directory (OVD) - access control rules
Oracle Internet Directory (OID) - access control policy points and privilege groups
Oracle Entitlement Server (OES) - role and access policies
Oracle Identity Federation (OIF) - in federation protocols; usually deployed with OAM
Oracle Web Services Manager (OWSM) - assertion-based policies
Oracle Adaptive Access Manager (OAAM) - rules-based policies
In order to enforce the entitlement, it (entitlement) must be first provisioned to the target system and second associated with a subject (user, group, application,etc). This is where a lot of painfully expensive steps happen because much of the workflow involves people from different teams. Throw in approval requirements, throw in eventual upgrades of target systems (Oracle e-Business Suite 11.x -> 12.x = potentially thousands of entitlement changes), throw in audit and compliance (does this person still need this entitlement) and you've got an unmanageable mess on your hands. We've seen and tackled this problem of managing entitlements' lifecycle so many times that we've got it down to science. Come to our webinar to find out more about managing entitlements and using Oracle Identity Manager as a platform for keeping them under control.
Oracle Virtual Directory (OVD) - access control rules
Oracle Internet Directory (OID) - access control policy points and privilege groups
Oracle Entitlement Server (OES) - role and access policies
Oracle Identity Federation (OIF) - in federation protocols; usually deployed with OAM
Oracle Web Services Manager (OWSM) - assertion-based policies
Oracle Adaptive Access Manager (OAAM) - rules-based policies
In order to enforce the entitlement, it (entitlement) must be first provisioned to the target system and second associated with a subject (user, group, application,etc). This is where a lot of painfully expensive steps happen because much of the workflow involves people from different teams. Throw in approval requirements, throw in eventual upgrades of target systems (Oracle e-Business Suite 11.x -> 12.x = potentially thousands of entitlement changes), throw in audit and compliance (does this person still need this entitlement) and you've got an unmanageable mess on your hands. We've seen and tackled this problem of managing entitlements' lifecycle so many times that we've got it down to science. Come to our webinar to find out more about managing entitlements and using Oracle Identity Manager as a platform for keeping them under control.
by Deborah Volk on Wednesday August 05, 2009
2 comments
It has been years, literally, since I have heard anyone talk about agent vs agentless. Both sides have spoken, and I believe the resolution has been passed: Agentless (by that I mean nothing installed remotely from the server) whereever possible, then use agents. And in today's climate of open standards and secure communications, it seemed like "whereever possible" was everywhere. Thus, the debate died and it became an afterthought.
Then comes Microsoft Exchange 2008.From a remote java perspective, Microsoft Exchange was all figured out.Java applications utilized JNDI to communicate with the MS Active Directory Domain Server to set initial MS Exchange attributes, then the MS Exchange's RUS (Recipient Update Service) finishes the object.There are certainly some inherent problems in this approach (for example, latency from the service perspective), but it allowed a remote (from the AD/Exchange domain controller) application to provision MS Exchange.And that remote application did not even have to be running on a windows machine -- a truly agentless topology.With the issues facing the Exchange RUS, Microsoft decided to remove part of this service in MS Exchange (for a good blog entry on this, read here) and make the user fully provisioned once they are created in the console GUI or by command line.Making the logical leap, we can then assume that the way to get users fully provisioned is through the console GUI (ADSI) or by command line (which in fact is true, as the cmdlets are the "API" to Exchange now). This is fantastic, your application is residing on a machine with the Exchange Management Shell(command line) or it has monkeys working in the background fat-fingering in data in the GUI.But if your application isn't in either one of these situations, then you are back to one less agentless connector in your pod.
For the IDM tools that are used to playing with older applications that didn't make it into the alphabet soup of communication standards, this isn't much of a problem as far as implementation of a solution is concerned.But for IT operations everywhere, the age-old, dead-horse beaten agent/agentless argument will start rearing its ugly head again.
by Deborah Volk on Tuesday July 21, 2009
no comments
Even with more daylight, I struggle with finding enough time to juggle family, work, and blog (not necessarily in that order, but pretty close most days). As a result of increased activity, I have been silent on the blogging front. This is not to say that I have not been thinking about all the interesting things to write about. With the workload increasing, the number of topics that I would like to discuss in an online forum also grows. Unfortunately entropy is hard to beat and without a perpetuum mobile as a source of energy, I have to find that elusive equilibrium between space and time. Thus we arrive at: How Authoritative is Authoritative?
If you have been reading our blog for a while, you will know this is not a new theme. It seems that a heretofore undiscovered sequence exists in Nature: skeptics -> identity management folks -> Identigral. For evidence, see Seek and Destroy (and itscounterparts), Spring Cleaning, and Through the Looking Glass (our data quality entries)). In earlier posts we looked at these issues from a perspective of a specific use case with only one common underlying theme: checks and balances. If the IDM solution is told by the business "this is our authoritative source of information," is the IDM team supposed to take everything at face value, with no inspection?
At Identigral, we are proponents of checks and balances (ergo, the common theme in all of the aforementioned posts) ... but can the IDM program be proactive when it comes to "bad data" in the authoritative systems? After all, based on extensive, peer-reviewed identity management research that runs many volumes and comes with serious statistical analysis (read: anecdotal evidence gathered by Identigral), bad data is expensive. It is a broken spoke that stops the wheel from turning smoothly, causing exceptions to bubble up in an otherwise automated process. When exceptions happen, people become part of the process and that's expensive. In the IDM world, multiple teams of people spanning groups, applications and continents might become part of the process and that's VERY expensive.
Let's segregate the data into different types of "badness":
1) Typo or data entry error
2) Deterministic errror in systems which causes generation of bad data (e.g., a script that terminates everyone)
3) Malicious data change (e.g., an IT support person promoting himself 3 pay grades during a change implementation)
The first type of error is very hard to detect. It typically affects a few records and there might be very little correlation to any other event or data related to the user who was typoed (yes, that's a new verb). Obviously, there are some rules that might be applied to certain data fields: certain addresses are invalid, some job code, department code combinations are invalid, etc. But, for the most part, these will go unchecked and result in the necessity of "spring cleaning" and "checks and balances."
The second type of error is usually caught and the cost associated with these errors isn't in a failed audit or damages but rather in clean-up operation. The clean-up is a very manual and labor-intensive process because IDM solutions don't account for the mis-hiring or the mis-firing scenarios. They're not resilient to failure. There are two things the IDM solution designers can do: 1) Put in processes to deal with mis-hires, mis-fires, and mis-updates and 2) With some relatively simply analytics, a system could tell if 100 terminations in 1 hour is out of the norm, or if people are hired in California on Christmas Day (and you are a bank, as opposed to a grocery store). Fancy analytics is expensive and it's usually applied in scenarios with a lot of data, e.g. modeling the fraud risk on a credit-card transaction based on patterns detected in 100 million other transactions. But there are some simple threshhold-based checks that could be put in an IDM solution that could lower the cost of cleanup efforts when something goes wrong. If you want to get fancy, you can make your thresholds be adaptive by using a linear transformation. This technique (albeit in a different domain) is described in Traffic Jams blogs.
The third type of error is the hardest to detect, especially given the ubiquitous assumption that if you have the right to do something you are allowed to do it. So if a support person can adjust his pay grade, then voila! he has been adjusted. Segregation of Duties and, broadly speaking, GRC solutions are supposed to prevent this from occurring but how many companies out there have a working Segregation of Duties or GRC implementation? While you wait for that, you can catch some malicious events in the IDM land by analyzing the events coming from the data sources. In fact, the bulk of work in a GRC implementation is coming up with credible detection rules that reflect the business and not just flag generic "write a check, approve a check" type of scenarios. If you can come up with these rules, you can put them to work in IDM by looking at incoming events.
Let's segregate the data into different types of "badness":
1) Typo or data entry error
2) Deterministic errror in systems which causes generation of bad data (e.g., a script that terminates everyone)
3) Malicious data change (e.g., an IT support person promoting himself 3 pay grades during a change implementation)
The first type of error is very hard to detect. It typically affects a few records and there might be very little correlation to any other event or data related to the user who was typoed (yes, that's a new verb). Obviously, there are some rules that might be applied to certain data fields: certain addresses are invalid, some job code, department code combinations are invalid, etc. But, for the most part, these will go unchecked and result in the necessity of "spring cleaning" and "checks and balances."
The second type of error is usually caught and the cost associated with these errors isn't in a failed audit or damages but rather in clean-up operation. The clean-up is a very manual and labor-intensive process because IDM solutions don't account for the mis-hiring or the mis-firing scenarios. They're not resilient to failure. There are two things the IDM solution designers can do: 1) Put in processes to deal with mis-hires, mis-fires, and mis-updates and 2) With some relatively simply analytics, a system could tell if 100 terminations in 1 hour is out of the norm, or if people are hired in California on Christmas Day (and you are a bank, as opposed to a grocery store). Fancy analytics is expensive and it's usually applied in scenarios with a lot of data, e.g. modeling the fraud risk on a credit-card transaction based on patterns detected in 100 million other transactions. But there are some simple threshhold-based checks that could be put in an IDM solution that could lower the cost of cleanup efforts when something goes wrong. If you want to get fancy, you can make your thresholds be adaptive by using a linear transformation. This technique (albeit in a different domain) is described in Traffic Jams blogs.
The third type of error is the hardest to detect, especially given the ubiquitous assumption that if you have the right to do something you are allowed to do it. So if a support person can adjust his pay grade, then voila! he has been adjusted. Segregation of Duties and, broadly speaking, GRC solutions are supposed to prevent this from occurring but how many companies out there have a working Segregation of Duties or GRC implementation? While you wait for that, you can catch some malicious events in the IDM land by analyzing the events coming from the data sources. In fact, the bulk of work in a GRC implementation is coming up with credible detection rules that reflect the business and not just flag generic "write a check, approve a check" type of scenarios. If you can come up with these rules, you can put them to work in IDM by looking at incoming events.
by Deborah Volk on Thursday June 11, 2009
no comments
As the summer descends upon us, so have various industry conferences. With that raison d'etre, a rising tide of interesting discussions is sweeping across blogs and other assorted outlets of identity and access management sound and fury. Mark Diodati from the Burton Group weighed in on the ontological issue of privileged accounts and people who (ab)use them. The linguistic conundrum seems to be in differentiating Privileged Accounts from Privileged Users. The secret sauce of securing privileged accounts according to Burton is based on managing two ingredients: WHO has access to the accounts and WHAT the accounts can do.
In my experience, the WHO/WHAT (WW) aspects are important to know and manage with respect to Privileged Accounts...but they (aspects, that is) don't change often. If you give a storage administrator access to all storage servers on a particular production cluster via a privileged account, you don't want to restrict the capabilities of this account or the storage admin may not be able to do his job. This would leave all those database-hungry customers in a bind (pleeeeeease, Dear Sir/Madam storage admin, could I have another 50 GB of space on your Most Blessed SAN array today and 50 more tomorrow). Nor would the storage admin ever share his account with anyone outside the usual few people in the storage admin group, so the WHO essentially does not change. What is truly important to manage (choke with a kung-fu grip) is the WHEN of the privileged account. When is the storage admin allowed to make production changes? (If you answered 'anytime', remove yourself from these Internets).Solutions from vendors such as Passlogix and Cyber-Ark attempt to address the when by limiting the check-out of the password to the privileged account owner. This works well if the privileged account is not the sole account of a user on that system. Unfortunately, this is not always the case. Let's take our happy storage admin as an example. He has an account BOBW on storage array bigwhopper.mycompany.com. He monitors various storage parameters on a regular basis via a few shell commands, so he needs read access every day. Unless you're looking at your CEO's paycheck, read access is not considered an elevated privilege by auditors. But anytime the byte-hungry database hosted on the storage array goes through a planned change, Bob needs to run a series of scripts to snapshot the database, create copies of certain storage volumes and clean-up the previous snapshots by moving them offline.
He now needs the ability to read files, create files, perform various storage array operations and eventually delete files. He only needs this access during the planned change window. At this point, you can either create a second account for Bob that has these specific privileges, but Bob can only use this account during the appropriate period (a password vault solution can work here), or you can grant the appropriate access and then revoke it after a given time period. The third approach is just to give him the access and to trust him.
The first approach, letting Bob have two accounts, would work, except now your audit processes have to deal with two accounts. If you have implemented an identity management solution and you had the amazing foresight to provide for this possibility, you will have both accounts show up as belonging to Bob, one temporarily belonging. There are organizations who elect to take this approach. They would rather keep the privileged accounts separate from the day-to-day, 'normal' accounts. The disadvantage of this option is that it increases the work that auditors and attesters have to do. They also have to have a razor-sharp knowledge of storage administrator group processes to recognize that account BOBW1 is the 'normal' account and 'BOBW2' is the privileged account.
The second approach (timeboxing the account use) truly mimics what the business case calls for but there's a technology catch. If you don't have an automated system that can enforce timeboxing, it would quickly become an administrative nightmare. Now, you might be thinking to yourself "isn't this the WHAT of an account?" In part it is, because you are changing what a person can do. But an equally or perhaps more than equally important factor is what the person can do relative to the context the person is in (the WHEN). Situationists of the world, rejoice.
All dreaming of cookies and milk aside, the third approach seems to be the one we encounter the most in the bright-lights world of IT. Mainstream adoption of sophisticated access management technology and business/IT change of related processes just aren't where they need to be at this point in human history. Thanks to Burton's opening shot in this novel, perhaps the software vendors will feel the anguish of security professionals and start developing products to help lock down access without jeopardizing the work that needs to be done.
...or perhaps the old ruler on the knuckles approach needs to be explored as an enforcement alternative. Contact us, we can help. (We'll bring our own rulers while supplies last).
The second approach (timeboxing the account use) truly mimics what the business case calls for but there's a technology catch. If you don't have an automated system that can enforce timeboxing, it would quickly become an administrative nightmare. Now, you might be thinking to yourself "isn't this the WHAT of an account?" In part it is, because you are changing what a person can do. But an equally or perhaps more than equally important factor is what the person can do relative to the context the person is in (the WHEN). Situationists of the world, rejoice.
All dreaming of cookies and milk aside, the third approach seems to be the one we encounter the most in the bright-lights world of IT. Mainstream adoption of sophisticated access management technology and business/IT change of related processes just aren't where they need to be at this point in human history. Thanks to Burton's opening shot in this novel, perhaps the software vendors will feel the anguish of security professionals and start developing products to help lock down access without jeopardizing the work that needs to be done.
...or perhaps the old ruler on the knuckles approach needs to be explored as an enforcement alternative. Contact us, we can help. (We'll bring our own rulers while supplies last).
by Deborah Volk on Friday June 05, 2009
no comments
Ask Identigral is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we're striving for in our blog. Since Abby isn't very good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here.
What is the best way to customize Oracle Identity Manager user interface?
When customizing any enterprise-grade product, the first question you (and your clients) should ask is what happens when the product is upgraded. Will you have to provide your own framework and process for maintaining your changes as the product is patched and upgraded? That is the question, as they used to say in ye olde England. Oracle Identity Manager is no exception to the rule. The approach you take for customization can have a signficant impact on the amount of time it takes to patch and upgrade your identity management infrastructure.First, the basics. Oracle has a document that goes over simple customizations to the Oracle Identity Manager user interface, the document being Administrative and User Console Customization Guide. While there are numerous other ways to accomplish the same goals as those in the guide, following Oracle's suggestions will help you stay out of major trouble.
If you have a requirement where you deduced that a customization is necessary and the customization doesn't fit the norm, it is not addressed in the aforementioned Oracle Identity Manager documentation, then there are four generic approaches available to you:
1) Modify the JSPs to get the behavior you want
2) Write new JSPs (and/or action classes and/or other supporting code) to do exactly what you want. Have your new pages be called from somewhere in OIM web UI, e.g. a new menu item that you might have added
3) Extend the action classes to either override out-of-the-box OIM functionality or add additional functionality
4) Forgo the OIM web UI altogether and roll your own
To choose from these approaches, we have to agree on what's important to us. If we define our goal and key evaluation criterion as being able to draw a line in the sand between our changes and vanilla OIM so that we won't get hurt by patches or upgrades, then none of these are perfect. Our own user interface (approach #4) comes closest but even then there's a large underlying assumption that all interaction between the custom UI front-end and OIM would proceed via official, publicly documented APIs. This may or may not be true, it depends on the requirements.
Whenever you modify a JSP, you will have to merge those changes back into the post-patch or post-upgrade OIM codebase. Having a robust source control system with good merge tools will help speed this up and not make it too onerous but there's a catch. A merge might be easy to accomplish in terms of joining two text files and figuring out what line goes where, creating one physical whole with correct structure but that does nothing for the meaning of that new whole. The new code may end up behaving in a completely different way. Logically, the merge is not complete without regression tests that prove your new page works under the same set of inputs as prior to the merge. The only benefit of directly editing a JSP is that you may not need a server restart to see the changes although that also depends on your app server settings and your strategy for deploying the modified JSP.
Adding your own pages, or extending the classes, typically requires one or more changes to be done to xlWebAdmin.properties, struts-config.xml, tiles-def.xml (there are a couple other files). Modifying these files may require a restart depending on your application server and how it was configured. The advantage of this approach is that there's no code merge, only XML and properties so there's no need for regression tests on existing pages although running them never hurts. With this approach Oracle can add or change features on the web client and usually (but not always) those changes will not have any impact on your custom code.
Thus, our advice is to evaluate the requirement driving the change. I've seen great many cases where the UI customization was not necessary, another solution that did not require that was possible. If there's no way around the customization, think about the type of change you're going to be making. Consider the frequency of future changes to the same component, the size of the change and whether there are any major updates or revisions to the general area of the user interface planned by Oracle and placed on the roadmap. Come up with a policy and a process to deal with all types of customizations so your team follows the same approach for each class of changes. Last but not least, ensure you've got a build & release process to deal with merges and regressions.
Have a Question?
Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc
Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc
Search
Recent Posts
Topics
Access Management (19)
Ask Identigral (6)
Change Management (10)
Data Quality (4)
Identity Management (27)
Passlogix v-GO (3)
Sun OpenSSO (3)
Sun Role Manager (3)
Tags
11g 3rd bday JavaOne SAML academia accuracy active directory adapters administrative agilent ask identigral attestation audit bpel bpmn bpm business case cdi cloud computing connectors contextual search data masking data quality deployment dip entitlements federation gartner groups gtc guests insider threats insider threat java jca jms lifecycle limericks linux mashup mdm messaging migration nabaztag oaam oam oas obiee oc4j oel off-boarding ohs oid oif oim oow09 opensso operations osso ovd owsm passwords patching performance phi privileged accounts provisioning queues reconciliation risk rocks rogue accounts rsa10 semantics siem sim sjsds sod solaris suncle thermodynamics twitter virtual reality vpd waveset webinar whitepapers