Analyzing Identity

Here is the third installment in a series of conversations I have had with James McGovern, enterprise architect extraordinaire. In this post, we expand the scope from insurance scenarios to include some broader enterprise contexts for externalized authorization.

JM: Over the last couple of years, I have had lots of fascinating conversations with Architects in Fortune enterprises regarding their Identity Management deployment and several common themes have emerged including that while they could do basic provisioning of an account in Active Directory, they couldn’t manage to successfully provision many enterprise applications due to challenges that go beyond simplistic identity. Can XACML help get them to the next stage of maturity?

GG: Your question reminds me of the latest round of commentary regarding the futility of a provisioning approach to identity management. Particularly from the latest Gartner IAM summit, speakers were lamenting the state of the provisioning market and how little progress has been made over the last 10 years. At the heart of the problem is the fact that provisioning tools just don’t have visibility into application privileges and entitlements, in the vast majority of deployments. Instead, provisioning deployments tend to “skim the surface” by managing userIDs/passwords, but defer deep entitlement settings to the target application or platform. Of course, the most difficult applications to manage are an issue because they don’t properly externalize identity management functions – making provisioning deployments more expensive as well as less than optimal.

Enter the “pull” model espoused by my former colleague, Bob Blakley. The basic premise of the pull model is that identity data is resolved at runtime by calling the appropriate service. If a user accesses an application before authenticating, redirect them to an authentication service. If a user accesses the application with a known token, redirect to the token service for proper handling. When the user attempts to perform a protected function, an authorization service should be called for evaluation.

As the reader may have surmised, the more an application externalizes identity – the less provisioning is required. Instead of provisioning accounts and entitlements to every application, a smaller number of authoritative identity service points are provisioned that can be leveraged by many applications. COTS applications would come preconfigured with policies for entitlements and authorization, instead of using a proprietary, embedded approach. To extend this further, access controls for COTS applications from different vendors can be implemented consistently – without excess access “leaks” – if they share a centralized access control model.

Therefore the ability to centrally describe the authorization model of an enterprise application would help. The challenge of identity management would significantly change in a number of ways. For example, enterprises would need to establish with identity services they would provision for the purposes of authentication – and which established, external identity providers they would consume. Authoritative attribute sources would fall into the same category. Finally, authorization policy modeling and management skills would become more prominent so that a normalized view could be attained across the enterprise.

JM: I remember conversations with my former boss at The Hartford where he asked me to explain the value proposition of identity management. He didn’t understand the value of spending millions of dollars for a system to tell him that James McGovern is still an employee. After all, he would know whether he fired me or not. What he wanted to know is what James McGovern could access if he decided to fire me. More importantly, even being in the role of Chief Security Architect, I couldn’t always figure out what I had access to.

GG: Sure, your boss would know whether he fired you or not – but what about all those independent insurance agents we’ve discussed in previous scenarios? Dealing with hundreds, thousands or millions of users and managing what they have access to is what drives organizations to spend significant sums on identity management. That said, there is often a budget imbalance because internal systems are more complex and expensive to operate than the applications serving external constituencies.

Determining what resources a particular user has access to, or who has access rights to a resource are questions that auditors, as well as system administrators, want answers to. Administrators need to know this detail so they can properly set up access for a new employee, contractor, customer, etc. Of course they also need to know this information so de-provisioning can also occur when the relationship is terminated. Auditors and regulators are responsible for ensuring that the organization is following internal business and security policies, as well as regulations or laws they may be subject to.

Current practices, where identity and policy are embedded in each business application, have proven to be very inefficient when attempting to audit the environment. It is not unusual for large organizations to have several hundred or a few thousand applications – imagine trying to audit such an environment on a regular basis if the identity information and policy is not externalized? The situation can be utterly insane if each application has its own store of user data, because then you have a synchronization and reconciliation challenge. Herein lies one of the main value propositions of externalizing authorization: audit-ability and accountability are much easier to accomplish because you have a central place where policies are defined and maintained (although the enforcement of those policies can certainly be distributed). Further, when you think of combining externalized authorization and identity governance, then you can achieve even more visibility and transparency into access controls.

JM: Many Architects have enterprise initiatives to reduce the number of signons to enterprise applications a user has to provide in any given day. Once they have implemented the solution to carry a token that provides seamless access between systems, they now discover that they have an authorization problem. What role should XACML play in an identity strategy?

GG: Sounds like that famous Vegas game, whack-a-mole. As soon as you think you have solved one problem, a new one appears… The scenario you describe can occur if the architects have not fully mapped out their strategy or understood the full consequences (intended or otherwise) of the architecture. If you move to a tokenized authentication approach (like SAML), then you have accomplished two worthy goals: reduced signon for users and fewer systems to provision a credential to.

However, as you point out, the application still needs to do authorization in some way. This could be accomplished if the application retains some kind of user store and keeps entitlement or personalization attributes about the user – at least the application is not storing or managing a credential. Thinking back to the issue of hundreds or thousands of applications, this doesn’t sound like a good solution for a number of reasons.

The preferred approach, if you have externalized authentication, is to also externalize authorization and utilize an XACML system. When the user presents their SSO token of choice to the application, it can call out to an XACML policy engine (such engine could also be embedded in the application for lowest latency) for the authorization engine. This is the approach we see more and more organizations taking.

JM: The average Fortune insurance enterprise may have hundreds of enterprise applications where maybe only 20% are commercial off-the-shelf (COTS) products. Vendors such as Oracle, IBM and SAP are providing out-of-the-box integration with XACML in future releases of their ERP, CRM, BPM, ECM and Portal products. Other large enterprise vendors however seem to be missing in action. How do I fill in the gaps?

GG: This is where you need to rely on your authorization vendor to provide PEPs for COTS applications that don’t directly support XACML. In some cases, you can use a proxy, custom PEP code or an XML gateway (such as from Layer 7, Intel or Vordel) to intercept calls to the application. In other cases, a hybrid approach is necessary because the application cannot operate unless users are provisioned into certain roles or groups.

Ultimately application customers have a lot of influence with their vendors on what standards should be supported. Enterprises should use what leverage they have to encourage XACML adoption where appropriate – that leverage could come in the form of willingness to buy the application if standards are supported vs. building it internally if the required standards are not included.

JM: Many corporations have SoX controls not only around IT systems but also physical security. Does XACML have a value here?

GG: There is definitely a use case where XACML authorization is the policy engine for converged physical/logical access systems. We are seeing some interest for this capability in certain defense scenarios and are working with a physical access vendor on some prototypes. The idea is that access decisions be determined not only based on typical logical access rules, but also based on where you are located. For example, the batch job for printing insurance claim checks will only be released once I have badged into the print room.

JM: So far, the conversation around identity has dominated many of the industry conferences and analyst research. The marketplace at large is blissfully ignorant to the challenges of managing entitlements within an enterprise context. What do you think will be the catalyst for this getting more airtime in front of IT executives?

GG: I think there are significant challenges that are forcing the issue of entitlements to the surface.

1. The need to share: an organization’s most valuable and sensitive data is precisely the data that partners, customers, and suppliers want access to. The business imperative is to share this data securely.
2. Overexposure of data: The counterpoint to the first item is that too much data is exposed – that is, sharing of sensitive data must be very granular so that the proper access is granted, but no more.
3. Sensitivity of data: We are in an era of seemingly continuous incidents of personal data release – either accidentally or due to poor security controls. Insurance companies collect lots of personal data such as what car you drive, where you work, what valuables you have in your home, medical information, insurance policy data, workers compensation data, etc. All this data needs to be protected from improper disclosure.
4. Moving workloads to the cloud: Regardless of all the hype around cloud computing, there is a strong drive to utilize the capabilities of this latest computing movement. What’s particular to entitlements surfaces in at least two areas. First, it is almost impossible to move workloads out of their traditional data center if entitlements and other IdM functions are “hard wired” into the application, because the application will cease to function. Second, once applications are moved to the cloud, you need to have a consistent way to enforce access – regardless of where the applications and data are hosted. This cries out for a common entitlement and authorization model that can be applied to all resources.

JM: I have some really wild scenarios in the back of my head on how XACML could enable better protections in relational databases, be used for implementing user privacy rights in enterprise applications and even how it could be used  as a way to provide digital rights management. What are some of the more novel uses of XACML that are on your radar that you think the information security community should be thinking of?

GG: The XACML policy language and architectural model are incredibly flexible and applicable to many business scenarios. Databases pose a particular challenge, but there are certainly creative ways to address this and it would be great to explore some of your ideas. Privacy scenarios have their own challenges because you can have legal restrictions on PII as well as user preferences to accommodate. At Axiomatics, we always welcome input from potential customers on their most challenging authorization scenarios to see how they we can meet their requirements.

Biographies for James and Gerry:

James McGovern

James McGovern is currently employed by a leading consultancy and is responsible for defining next-generation solutions for Fortune enterprises. Most recently he was employed as an Enterprise Architect for The Hartford. Throughout his career, James has been responsible for leading key innovation initiatives. He is known as a author of several books focused on Enterprise Architecture, Service Oriented Architectures and Java Software Development. He is deeply passionate about topics including web application security, social media and agile software development.

James is a fanatic champion of work/life balance, corporate social responsibility and helping make poverty history. James heads the Hartford Chapter of the Open Web Application Security Project (OWASP) and contributes his information security expertise to many underserved non-profits. When not blogging or twittering, he spends time with his two kids (six and nine) who are currently training to be world champions in BMX and Jiu-Jitsu.

Gerry Gebel, President Axiomatics Americas

As president, Gerry Gebel is responsible for sales, customer support, marketing, and business development for the Americas region. In addition, he will contribute to product strategy and manage partner relationships for Axiomatics.

Prior to joining Axiomatics, Gebel was vice president and service director for Burton Group’s identity management practice. Gebel authored or contributed to more than 70 reports and articles on topics such as authorization, federation, identity and access governance, user provisioning and other IdM topics. Gebel has also been instrumental in advancing the state of identity-based interoperability by leading demonstration projects for federation, entitlement management, and user-centric standards and specifications. In 2007, Gebel facilitated the first ever XACML interoperability demonstration at the Burton Group Catalyst conference.

In addition, Gebel has nearly 15 years experience in the financial services industry including architecture development, engineering, integration, and support of Internet, distributed, and mainframe systems.

Here is part 3 of a conversation with Gunnar Peterson where we continue talking about externalized authorization, who in the organization is involved in an XACML system deployment – and it even includes a discussion of TOCTOU concerns as it relates to a XACML system. Thanks also to my colleagues, David Brossard and Pablo Giambiagi, for their input. You can also find part 1 and part 2 of the conversation on this blog.

The conversation with James McGovern continues… here is the next installment in a series of posts on the applicability of XACML-based authorization for the insurance industry:

JM: We had a great discussion covering basic entitlement scenarios and how they can be applied to the insurance vertical. Are you ready for some scenarios that are more challenging?

GG: Absolutely…

JM: Let’s dive into two additional insurance-oriented use cases. First, let’s talk about the concept of relationships and how they challenge the traditional notions of authorization and role-based access controls. Imagine you are a vacationing in sunny Trinidad and have left your nine-year old child home alone. Your son having been raised by responsible parents decides to renew your automobile registration in order to avoid paying a late penalty but realizes he needs to also get an automobile insurance card first. How does the insurance carrier determine that your son is authorized to request an insurance card for your policy, the answer is via relationships.

Relationships in an insurance context may be as simple as confirming whether the subject is listed as a named insured on a policy or could be more complicated in scenarios where there is a power of attorney in place where someone with a totally different name, address and otherwise unrelated may be authorized to conduct business on your behalf.

GG: This is an excellent case where the PIP interface of the policy server can call out to a directory, customer database, or web service to determine if the requestor has a relationship with the policy holder. Having the policy server, the PDP in XACML parlance, make the query simplifies things for the PEP and application. Instead, the PDP figures out what additional attributes are necessary to satisfy a particular policy.

JM: Relationships can be modeled in a variety of manners but generally speaking can be expressed in either a uni-directional or omni-directional manner. For example, a husband and wife have a bi-directional relationship to each other than can be named as a spouse while an elderly person may have a uni-directional relationship where the person holding the power of attorney can take actions on behalf of the individual but not vice versa.

GG: Again, XACML policies and the PDP can evaluate relationships between entities to resolve access requests. In this example, a person with power of attorney for a parent’s account can make changes to that account because a condition in the XACML rule can dynamically validate access. Spouses can have common access to update insurance policies that they co-own because each is named on the insurance policy – again the XACML condition easily evaluates the relationship: user_attempting_access == named_insured. In this example, named_insured could be a multi-valued attribute that lists parents and children on the insurance policy. The PDP must be able to parse through the multiple values when evaluating access policies. To add another layer of context, each of the persons in the named_insured list could have different privileges where children are allowed to view the insurance policy, but not able to update or cancel it.

JM: In the model of delegation, the power-of-attorney may have a specified scope whereby the person holding the power-of-attorney can do actions such as make bill payments or make endorsement changes but may not have the right to cancel.

GG: The flexibility of XACML policy is evident for this case as well. For example, Policies can have a “target” so that particular effects can be implemented in each scenario. In the above example, a policy with a target of “action=cancel” can have a rule that denies the action, while other actions are permitted. Alternatively, policies could be created for each action and combining algorithms resolve any conflicting effects. Combining algorithms are defined for deny overrides, permit overrides, first applicable, and several other results.

JM: Let’s look at another insurance scenario. Within the claims administration process, you can imagine that the need for a workflow application (BPM) along with a content management application (ECM) would be frequently used. From a business perspective, you may have a process known as First Notice Of Loss (FNOL) whereby a claimant can get the claim’s process started. The BPM process would handle tasks such as assigning a claims handler to adjudicate the claim while the ECM system would capture all the relevant documentation such as the police reports, medical records if there were injuries and photos of the car you just totaled.

Now, let’s imagine that a famous person such as Steve Jobs or Warren Buffett is out driving their Lamborghini and get’s into an accident. For high-profile people, you may want to handle claims a little differently than for the general public and so you may define a special business process for this purpose. The big question then becomes, how do you keep the security models of the BPM and ECM systems in sync? More importantly, what types of integration would be required between these two platforms.

GG: First, access policies should be designed to restrict claims processors to only handle claims that are assigned to them, or their team. This can be accomplished dynamically through the use of conditions, independent of what users get assigned to teams or groups. As noted earlier, the PIP interface is able to look up group or team membership at runtime. In addition, the insurance company may choose to implement an extra policy to further restrict access to celebrity or VIP clients. An example of where this would have been useful is the “Octo-mom” case where employees were found to have inappropriately accessed her records. The “celebrity” policy can be targeted to resources associated with an individual or they can be tagged with metadata indicating a special handling policy applies. In the PDP, results from multiple policies are resolved with the combining algorithms defined in XAMCL – first applicable, deny overrides, permit overrides, etc.

Regarding integration between BPM and ECM systems, it appears there are multiple options here. In one example, the ECM system can defer access decisions to the BPM layer, which can be effective if the only access to records is through the BPM layer. If access to ECM records flows through different applications, then both ECM and BPM should use the same authorization policies/system. If they use the same authorization system, BPM and ECM are using the same policies by definition and can therefore implement access controls consistently.

JM: It is a good practice to not only assign the claim to a team but for people outside of that team to not have access (in order to respect privacy). The challenge is that teams aren’t static entities and may not be statically provisioned. This model doesn’t just occur within business applications but is a general challenge in many enterprise systems. As you are aware, the vast majority of enterprise directory services tend to have a view of the organization and its people through the lens of reporting relationships and not team composition and how work actually gets done. The notion of the matrixed organization can further blur authorization models.

GG: I agree that directories are not always able to easily represent matrixed relationships within an organization. Ad hoc groups can be created for projects or teams, but can be difficult to manage and keep current. In some cases, virtual directories can provide a more flexible way to surface different views of directory data. The bottom line is that you can’t implement dynamic policies if the necessary relationship data is not available.

JM: Are there practices you recommend that enterprises should consider while modeling directory services to support authorization scenarios described so far?

GG: Yes, there are a number of things to consider regarding directory services when dealing with attribute based access control systems. In general, here are some key points:

• We tend to prefer using existing, authoritative attribute sources – rather than force any kind of directory service re-design. In typical organizations, this means that privilege-granting attributes could be stored in several repositories that include directories, as well as databases or web services. At some point, the organization may choose to implement a virtual directory product, which gives them a lot of flexibility in aggregating attributes and providing custom schemas for the various consuming applications – including ABAC systems.
• When constructing XACML policies, the policy author does need to think about where attributes are stored because of performance implications. Attributes may be local to the application or possibly remotely stored in another security domain. Even local attribute lookups can be an expensive operation if the repository does not operate efficiently. There are many techniques to deal with performance, but they must be dealt with in order to achieve adequate response times for interactive users.
• A corollary to the previous point is the question of what component does the attribute lookup, the PEP or PDP? The PEP will naturally have access to several attributes, such as userID, action, target resource, and some environmental variables. The PEP could look up additional attributes, but it does not necessarily know which policies will be evaluated. Therefore, it is normally better for the PDP to do attribute lookup after it determines what policy(ies) to evaluate.
• Data quality is always an issue in directory services. As a former colleague, Larry Gauthier, was fond of saying, “Even if you admit your directory data is dirty, it is most likely filthy.” Once an organization starts writing access policies that utilize dirty data, it’s possible that incorrect decisions could be the result. The solution isn’t necessarily technical, but could impact processes that are responsible for updating and maintaining user data – whether that’s in the HR system, enterprise directory, CRM database, or other repositories.

JM: Are you aware of any BPM or ECM vendors that are currently supporting the XACML specification? If not, what do you think enterprise customers can do to help vendors who remain blissfully ignorant to the power of XACML to see the light?

GG: I am not aware of any BPM or ECM vendors that support XACML today. Documentum has published how to add an XACML PEP to their XDB, but I don’t know of their broader plans, if any, to support XACML.

I think customers need to continue pressing vendors to externalize authorization and other identity management functionality from their applications. Customers can do this directly via their product selection process and by proxy through their industry analyst resources. ISVs should not expect to operate in a silo any more because applications have to interact with each other. It is extremely difficult to implement consistent access policy across multiple policy domains and you would think that application vendors have gotten this message by now. Further, XACML is a very mature standard that can be easily integrated into new application development and also feasible for retrofitting many existing applications. Again, the key is for customers and analysts to force the issue with application and infrastructure vendors.

Stay tuned for Part Three…