A single transaction in a standard enterprise architecture traverses multiple policy domains, namespaces, and technologies. Part of the problem to be solved by the security architecture is how to deal with authentication and authorization. At a high level there are subjects making requests objects and the communication is mediated by a Policy Enforcement Point (PEP).
Now the role of authentication services is verify and bind some set credentials onto token(s) that are used to make other decisions. The role of authorization is granting access, but where and where do you need to authenticate in a distributed system? In a single transaction lifecycle such as the one below, the user traverses a half dozen different technologies, namespaces, and so on. In addition,each system may rely on its own proprietary security mechanisms.
This is a very common scenario and far simpler than many architectures. So one question, is how far do you propagae the user's credentials? Do you keep a record on each user in all six systems? What abotu Oracle and SAP who (hypothetically of course) are charging you by the user? From a security standpoint do you really want to propagate identity hazmat (aka authentication credentials) throughout more than one system? Probably not. From a IDM standpoint how compelx do you want your provisioning to be? So in general, from an economic, risk, and compelxity standpoint, you probably want to limit all this to the extent you can. And instead push authentication to the edge of the system. The PEP (along with the PDP) has to map all its access control decisions to all its objects, so these will always, by necessity has some locality with the object it is protecting.
The best documentation I have seen in the open literature of the possible variants here is in Bob Blakley and Craig Heath's Security Design Patterns. This book contains the genesis of the problem we face
Security properties, especially authentication, often do not compose. Nevertheless, information systems are often built on composition.
They define a simple interaction with two possible guards
A secure proxy patterns deals with the following forces:
• The user would like to sign on only once.
• Both guards would like to authenticate the user.
• Both guards would like to enforce a policy based on the user’s identity.
• The authentication protocol may not authenticate the user to more than one partner.
• The user may not want (or be allowed, or be able) to divulge a passwordor other
authentication data to Guard1.
And they enumerate the following choices
Now the ideal scenario describes authentication (froma user standpoint_ occuring in only location so this resolves some of the aforementioned economic, risk, and compelxity issues. SSO (and SLO) which could be accomplsihed using SAML or other federation implementation. This is the ideal scenario, but none of the patterns individually give you exactly what you need. A combination of the patterns needs to limit the amount of authentication and instead use previously authenticated attributes to authorize access. Federation, then, is an enabling technology for these systems to work together.
Gerry Gebel raises some other salient authorization design considerations, which I will explore in the next post.
I blogged earlier about the ATM puzzle that Robert Morris Sr. gave at Blackhat awhile back. And as usual, we can learn a lot from ATMs. We have relatively strong 2 factor authentication at the edge, now there are many paritcipants between me and my bank, but my PIN code should not be revealed to all of them, right?
Update: Mark O'Neill weighs in on authorization in general, XACML in particular and how Vordel's products help you deal with it. Mark nails the importance of portability:
This is a big advantage XACML gives you. Your AuthZ requests suddenly are XML messages which can be routed, logged, monitored, and managed using standards-based infrastructure. I put this in bold type because it really is a big deal. AuthZ requests are no longer some piece of invisible "internal security plumbing". It means you can bring XML infrastructure (such as Vordel's :-) ) to bear on it.
So in a nutshell, step 1 is to decouple authN and authZ, step 2 is to use technologies and standards that enable you to use attributes that have already been authenticated to perform authorization.
Comments