Wednesday, December 24, 2008
Liberty Alliance 2.0
SAML 2.0 supports an XACML payload. Anyone care to guess why you can't find a single product that can't make effective use of this specification...
Imagine a scenario where you need to adjust the authorization model at runtime based on how a third-party defines their organizational structure where company A may want to access a system that displays commissions and they only want employees in the Northeast to see commissions generated in the Northeast. Likewise company B may want to restrict views into your commission system where they may be organized into two groups: individual and institutional. The permutations on how outside parties can organize is infinite and XACML is a great way to handle the description aspects without forcing provisioning of entitlements at each and every service provider.
You may have noted that many of the federated identity management products support bridging access into products such as Tivoli Access Manager, CA/Netegrity Siteminder, Oracle/Oblix CoreID and so on, but do so in a way that simply requests of these products that they generate a cookie and nothing else. At runtime, you can receive a wonderful SAML message containing XACML but it will get thrown away if you are using web access management solutions.
Likewise, the entitlements management vendors (e.g. Jericho Systems, Securent, etc) only think of entitlements as something within the enterprise (this isn't necessarily bad) where they are constrained in that they don't integrate with any of the federated identity management products (OIF, RSA FIM, etc), so I got this wonderful SAML/XACML thing happening but how do I get the entitlements management product to consume it. Of course you may have also noted there is a problem with session management in these scenarios in that web access management products should also cache the XACML and not think of them as one-time requests.
The entitlements management products in the scenario of commissions should allow one to say that a company can only access its commisssions which will prevent company A from seeing company B and vice versa. Likewise, it should also consume the SAML/XACML and apply additional restrictions.
Anyway, what does this have to do with Project Liberty? In order to have a cohesive identity ecosystem, it requires solving for issues that are a couple of degrees away from products that directly produce/consume identity. Web Access Management products need additional features, entitlements management needs a standards-based way of participating in federated identity and so on. Is anyone from Liberty noodling this? Probably not as most folks are still working on the basics. Of course, I can spend lots of money in order to gain influence which may never actually materialize, but at least I get to network with folks I probably would interact with for free anyway...
| | View blog reactionsImagine a scenario where you need to adjust the authorization model at runtime based on how a third-party defines their organizational structure where company A may want to access a system that displays commissions and they only want employees in the Northeast to see commissions generated in the Northeast. Likewise company B may want to restrict views into your commission system where they may be organized into two groups: individual and institutional. The permutations on how outside parties can organize is infinite and XACML is a great way to handle the description aspects without forcing provisioning of entitlements at each and every service provider.
You may have noted that many of the federated identity management products support bridging access into products such as Tivoli Access Manager, CA/Netegrity Siteminder, Oracle/Oblix CoreID and so on, but do so in a way that simply requests of these products that they generate a cookie and nothing else. At runtime, you can receive a wonderful SAML message containing XACML but it will get thrown away if you are using web access management solutions.
Likewise, the entitlements management vendors (e.g. Jericho Systems, Securent, etc) only think of entitlements as something within the enterprise (this isn't necessarily bad) where they are constrained in that they don't integrate with any of the federated identity management products (OIF, RSA FIM, etc), so I got this wonderful SAML/XACML thing happening but how do I get the entitlements management product to consume it. Of course you may have also noted there is a problem with session management in these scenarios in that web access management products should also cache the XACML and not think of them as one-time requests.
The entitlements management products in the scenario of commissions should allow one to say that a company can only access its commisssions which will prevent company A from seeing company B and vice versa. Likewise, it should also consume the SAML/XACML and apply additional restrictions.
Anyway, what does this have to do with Project Liberty? In order to have a cohesive identity ecosystem, it requires solving for issues that are a couple of degrees away from products that directly produce/consume identity. Web Access Management products need additional features, entitlements management needs a standards-based way of participating in federated identity and so on. Is anyone from Liberty noodling this? Probably not as most folks are still working on the basics. Of course, I can spend lots of money in order to gain influence which may never actually materialize, but at least I get to network with folks I probably would interact with for free anyway...
