Saturday, May 19, 2007
XACML and Provisional Authorization
Let me first start of by saying that existing authentication mechanisms are adequate and don't need to be overhyped like they currently are being done in the blogosphere. Once a client has been authenticated and the current role assigned, the client may make authorization requests. Where the conversation needs to shift away from identity and authentication towards authorization as this is a bigger unmanaged problem within large enterprises that folks such as Pat Patterson and others in the identity crowd aren't talking about. They will argue that they are being incremental and nailing authentication before moving on, which I think at some level is true but at other levels dishonest.
Almost all implementations of access control and authorization systems have assumed the following model: A user makes an access request of a system in some context, and the system either authorizes the access request or denies it. Have folks ever considered the notion of provisional authorization?
Here are some examples of provisional authorization that I would love to see folks from BEA, Sun, Securent, Netegrity and Oracle noodle:
- You are allowed to access confidential information, but the access must be logged
- You are allowed to read sensitive information, but you must sign a terms and conditions statement first
- If unauthorized access is detected, a warning message must be sent to an administrator
So, how does one model such things in terms of XACML policy? Maybe Gerry Gebel of the Burton Group could consider these scenarios as part of his interoperability lab at the Catalyst conference...
Links to this post: