James McGovern has a habit of posing questions and then naming the people he would like to answer them. This time around, I had the privilege of having my name read out on the roll call. Actually he posted it just before I went on my week-long holiday hence I'm only getting around to it now.
Here are his questions (in blue) and my attempts at some answers (hopefully I don't sound like a complete fool - I'll settle for mildly foolish):
[JM] Protocols:Nowadays, the folks over at the Burton Group such as Bob Blakely, Dan Blum and Gerry Gebel have put together the most wonderful XACML interoperability events. The question that isn't addressed is if I am building an enterprise application from scratch, should I XACML-enabled, think about integrating with STS, stick to traditional LDAP invocation or something else?
[IY] I'm not 100% sure what James is asking and my answer will probably be different if James actually means something other than what I've interpreted it as. I read the question as being once the decision's been made to use XACML, how should one be dealing with authentication? Talking about an STS (I assume James means Security Token Service) vs LDAP refers to 2 different "layers". In reality nowadays, you're ultimately authenticating to a directory of some sort. Usually you do this using the LDAP protocol under the covers. Whether you know this or not depends on the overall design.
Note that using XACML means you are pushing policy definitions around to ultimately get your Policy Enforcement Point to be able to come up with an authorisation decision. When you talk about STS or LDAP, you're typically referring to authentication which ultimately produces some sort of credential for the user within their session. Authentication and authorisation (or entitlements as people seem to like calling it nowadays) are related, but separate things that can be implemented differently as long as there is a point where they interoperate. Usually the most important part is where the authentication mechanism passes the security principal onto the authorisation mechanism so it can make an identity based, access control decision (that is also hopefully fine grained and context aware).
That said, I'm going to ignore the XACML consideration for a moment...
There are a few common approaches to take when writing authentication for applications:
1) Take a service-oriented approach (e.g. SOA or web services)
2) Leverage an API or application programming standard (e.g. JNDI, JAAS)
3) Use the native protocol of the authentication store (e.g. LDAP, SQL)
Option 1 is the most difficult to set up because this type of infrastructure is typically not built in organisations today. But it IS the most extensible option and hides the implementation specifics from every application that needs to perform authentication. Whether the underlying store is a directory, database, file system or even a mainframe does not matter. You also get the benefits served up by leveraging a web service. For example, you just need to know how to format your message (this is actually not a problem if you use a standard as it is usually taken care of by some other service) and where to send your request (via the URI). You obviously also need network connectivity to that location. There are no headaches around what libraries to import, whether your authentication services are co-located with your application or whether you need to go screw around with configuration settings and files because you are actually calling a service that is not located on the same application server as you. Keep in mind that you don't necessarily have to use an STS, although it is probably the best approach today if you're going with a service-oriented design.
Option 2 still leverages standards of sorts. JNDI and JAAS for example are both standards in their own rights. They just happen to be tied into a programming language and platform. This option is probably still easier than option 1 because organisations will more than likely have this infrastructure more or less set up. It's a matter of getting the programmers to code to these standards/APIs and then setting up the application infrastructure to hook into the relevant authentication stores. Again, this is probably already done if you're using a standards-based Application Server (e.g. J2EE). You will however, have configuration files to screw around with and changes to any of the infrastructure will potentially require applications to be modified. You're also tied into the platform somewhat. For example, if you use JNDI you're stuck with Java and the directory under the covers. With a web service, it doesn't really matter what programming language is used or what the authentication store is. You can swap components out without modifying the other loosely coupled pieces. You're supposedly able to do this easily if you code to API standards, but that's rarely true. There's usually re-configuration and some re-writing required.
Option 3 requires intimate knowledge of the protocol or tools required to access the authentication store. If using LDAP, you need to know LDAP query syntax. If using SQL, you have to know how to write SQL queries or stored procedures. It also means you cannot change your authentication stores and schemas without re-writing your applications.
They each have their benefits, but it boils down to the age old discussion around tight coupling vs loose coupling. The looser the coupling of your infrastructure components, the more extensible they are. You lose performance however and it usually takes more effort and time to build a loosely coupled system because of all the design considerations to take into account. (Note: The performance issue is usually one that can be designed around if you have the budget. You put enough redundancy, load balancers and hardware in place and you can usually get something to perform within your service level agreements (SLAs). If your network hops are large, just do a better job of negotiating your SLAs - easier said than done I know).
Option 1 is the loosely coupled approach which should "identity proof" your environment for a longer period of time (notice I didn't say forever). Option 3 is the tightly coupled approach. Option 2 is something in between. The one to pick depends on requirements, time and cost constraints. The choice will be determined by how much of the authentication infrastructure specifics you want to burden your developers with.
Bringing the XACML considerations back into the picture, I would go for option 1. If you're going to take the effort and XACML-enable your applications, why would you "get cheap" and not go with the use of an STS? It also makes everything nice and clean from an application programming standpoint. Developers will only have to worry about using security services. They won't need to remember that for certain security related things, they need to use the web service while for others they have to use the API or go direct to the source over LDAP or SQL.
[JM] Virtual Directories: What role should a virtual directory play in an Identity metasystem? Should virtual directory be a standalone product in the new world and simply be a feature of an STS? If an enterprise were savage in consolidating all directory information into Active Directory, why would I still need virtualization?
[IY] I don't come across too many organisations that use a virtual directory. Maybe it says something about the maturity of their Identity Management infrastructure. Or maybe it means that they don't see the need and are quite happy replicating things using meta-directories and synchronisation.
Leveraging a virtual directory is very much a technology choice and dependent on each organisational environment. If they have lots of identity stores and have a nightmarish amount of information that would take a long time to integrate and synchronise, then a virtual directory makes sense. If an organisation has a fairly small number of stores or their strategy is to leverage a specific central store like Active Directory, then they probably don't. On the flip side, one could argue that the virtual directory could become this "central store".
I'm not for or against virtual directories. I just think there's a time, environment and place for the choice between a virtual directory or a synchronisation solution like a meta-directory. As for using a virtual directory as part of an STS, the argument is very similar to what I've just outlined.
[JM] Entitlements: One missing component of the discussion is authorization and their is somewhat too much focus on identity. Consider the scenario where if you were to ask my boss if I am still an employee, he would say yes as he hasn't fired me yet. Likewise, if you ask him what are all of the wonderful things I can access within the enterprise, he would say that he has no freakin clue, but as soon as you figure it out, please let him know. Honestly, even in my role, there are probably things that I can do but shouldn't otherwise have access to. So, the question becomes how come the identity conversation hasn't talked about any constructs around attestation and authorization?
[IY] People are too busy crapping on about OpenID and CardSpace all the time :-)
Seriously, I think it's got to do with the way things in the identity space evolve. Before you can deal with entitlements and attestation, you need to know who people are and what they can use (i.e. what they can "log into"). It's a very high level approach sure. But that's how organisations typically start looking at the whole issue.
Also, Identity Management is not an easy issue to solve. As a result, it's taken a long time to get around to thinking about authorisation properly. It doesn't mean we will never get there. We just have to be a little more patient. All the GRC initiatives going on around the place are certainly helping. Attestation is usually one of the first things that get addressed in any GRC initiative because it needs to be done to satisfy the regulators and auditors.
Once organisations realise that having a proper authorisation infrastructure in place makes their lives a lot easier from a management and audit perspective AND it'll save them money (instead of having to re-invent the authorisation wheel for every application), they'll start to do something about it.
It's also about evangelism, education and focus. The focus isn't there yet so there's no education. Evangelism comes from the industry as a whole. The large vendors are usually the ones with the marketing clout to get the messages out in a meaningful way. Unfortunately, they chase the dollars. Until recently, there hasn't been sufficient sales revenue or qualified opportunities to justify evangelising authorisation. It's the next cab off the rank I think. We might have to wait a year or 2 for organisations to get through the early phases of their GRC initiatives before authorisation gains real traction.
[JM] Workflow: Have you ever attempted to leave a comment on Kim Cameron blog? You will be annoyed with the registration/workflow aspects. The question this raises in my mind is what identity standards should exist for workflow? There are merits in this scenario for integrating with the OASIS SPML standard, but I can equally see value in considering BPEL as well.
[IY] I don't think there needs to be identity standards for workflow in the traditional sense of technical standards. A generic workflow standard (e.g. BPEL) across all disciplines is good enough and will be better in the long run. Workflows are very dynamic, can get very complex and will be different for each organisation even if they are trying to do similar things. This makes standards tricky. Then there is also workflow from a business standpoint. When technical folk talk standards, they usually mean nuts and bolts (e.g. XML specifications). Those in the business world don't care that a worklow is written in BPEL. They care that they have to write a frigging workflow procedure from scratch. They would probably find some standards around business process definitions useful. It might be prudent of us to define easily extensible procedural workflow templates for Identity business transactions perhaps? Now that would REALLY be something.
[JM] Education: Right now the conversation regarding identity is in the land of geeks and those who are motivated to read specifications. There is a crowd of folks who need things distilled, the readers digest version if you will. Traditionally, this role is served by industry analysts such as Gartner and Forrester. What would it take for this guys to get off their butts and start publishing more thoughtful information in this space?
[IY] I don't think industry analysts are ever going to write a "readers digest" version of anything related to Identity. It doesn't help them make more money from selling reports and holding conferences for specialised groups of people while charging them thousands of dollars each. Unfortunately, I think the fastest way to get simplified Identity education out there is through the marketing dollars of the large vendors. Consulting organisations (including analysts like Gartner and Forrester) will never simplify anything because they need for things to remain (or sound) complex so they can keep charging for their "expertise".
[JM]Conferences: When do folks think that the conversation about identity will occur at other than identity/security conferences? For example, wouldn't it have been wonderful if Billy Cripe, Craig Randall and Laurence Hart where all talking about the identity metasystem in context of ECM?
[IY] Ummm how about never...which is fine by the way. The Identity industry needs to make things so dead simple and ubiquitous that there is no need to talk about it. It should just be there. Therein lies the challenge facing us all today.
No comments:
Post a Comment