Comments on: Directories 2.0 – entitlements services http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/ IT mixology and other thoughts about tech, life the universe and everything Mon, 21 Dec 2009 18:40:07 +0000 http://wordpress.com/ hourly 1 By: Why I’m a NAC nonbeliever « Chris Swan’s Weblog http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-57 Why I’m a NAC nonbeliever « Chris Swan’s Weblog Thu, 12 Jun 2008 14:41:27 +0000 http://thestateofme.wordpress.com/?p=19#comment-57 [...] where do we achieve policy enforcement points (PEPs)? The issue can therefore be recast in terms of entitlements services. It almost always makes more sense to put PEPs within applications or application infrastructure, [...] [...] where do we achieve policy enforcement points (PEPs)? The issue can therefore be recast in terms of entitlements services. It almost always makes more sense to put PEPs within applications or application infrastructure, [...]

]]> By: Chris Swan http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-49 Chris Swan Fri, 28 Mar 2008 11:52:19 +0000 http://thestateofme.wordpress.com/?p=19#comment-49 I was sent this link - http://directory.apache.org/community%26resources/ldap-renaissance.html, which is more directories 1.1 than 2.0, but nevertheless interesting. I was sent this link – http://directory.apache.org/community%26resources/ldap-renaissance.html, which is more directories 1.1 than 2.0, but nevertheless interesting.

]]> By: Craig http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-48 Craig Fri, 28 Mar 2008 10:14:37 +0000 http://thestateofme.wordpress.com/?p=19#comment-48 We can bring onto the agenda by sending an email to the list. I can handle doing that, it's just that right now is a bad time as everyone heads-down on the upcoming interop for RSA. I'll keep you posted on what happens in this regard. We can bring onto the agenda by sending an email to the list. I can handle doing that, it’s just that right now is a bad time as everyone heads-down on the upcoming interop for RSA.

I’ll keep you posted on what happens in this regard.

]]> By: Chris Swan http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-47 Chris Swan Fri, 28 Mar 2008 09:41:05 +0000 http://thestateofme.wordpress.com/?p=19#comment-47 Bradley - thanks for the pointer to ESOE, this looks really cool. It's not quite what I was asking for as it's moving complexity into the PEP rather than creating uniformity at the PDP, but I like the overall architecture. Any thoughts/plans about information card integration? Craig - I think a standard WSDL for the PDP service would be exactly what's needed. How do we get this onto the XACML TC agenda? BTW WSDL doesn't have to define a SOAP interface, it can be equally used for REST (though obviously the bindings aren't defined in the W3C standard). But... it seems that the solution space under discussion is converging on reusing a lot of stuff that's been done already with SAML, so I guess the angle brackets probably win out on this one. Bradley – thanks for the pointer to ESOE, this looks really cool. It’s not quite what I was asking for as it’s moving complexity into the PEP rather than creating uniformity at the PDP, but I like the overall architecture. Any thoughts/plans about information card integration?

Craig – I think a standard WSDL for the PDP service would be exactly what’s needed. How do we get this onto the XACML TC agenda?

BTW WSDL doesn’t have to define a SOAP interface, it can be equally used for REST (though obviously the bindings aren’t defined in the W3C standard). But… it seems that the solution space under discussion is converging on reusing a lot of stuff that’s been done already with SAML, so I guess the angle brackets probably win out on this one.

]]> By: Craig http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-46 Craig Fri, 28 Mar 2008 08:34:20 +0000 http://thestateofme.wordpress.com/?p=19#comment-46 Of course, by "simple as possible" I mean "as simple as possible by building on other specifications". A REST interface could (would?) be simpler in absolute terms, but using SAML to transport the XACML requests means we can leverage the defined SAML transport mechanisms. Gotta love having layers on layers of standards and protocols! Of course, by “simple as possible” I mean “as simple as possible by building on other specifications”. A REST interface could (would?) be simpler in absolute terms, but using SAML to transport the XACML requests means we can leverage the defined SAML transport mechanisms.

Gotta love having layers on layers of standards and protocols!

]]> By: Craig http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-45 Craig Fri, 28 Mar 2008 08:31:12 +0000 http://thestateofme.wordpress.com/?p=19#comment-45 You've got a good point about bootstrapping the communication process. What we've done for the OASIS interop events (I represented IBM at the Burton Catalyst Interop in 2007) is make it as simple as possible - send a SAML-wrapped XACML Request in a SOAP envelope to a given URL. This appears to be the approach taken by vendors prior to the events, so I don't think there's a big an issue as first appears. Perhaps a valid task for the XACML TC could be to define a standard WSDL for a PDP service? While we don't technically need a WSDL, it may help to allay concerns such as the ones you have. What do you think? A REST binding would be great too, but in all honesty I don't know enough about the technology to give a meaningful comment. I'm a SOAP + WS-* man. :P You’ve got a good point about bootstrapping the communication process.

What we’ve done for the OASIS interop events (I represented IBM at the Burton Catalyst Interop in 2007) is make it as simple as possible – send a SAML-wrapped XACML Request in a SOAP envelope to a given URL.

This appears to be the approach taken by vendors prior to the events, so I don’t think there’s a big an issue as first appears.

Perhaps a valid task for the XACML TC could be to define a standard WSDL for a PDP service? While we don’t technically need a WSDL, it may help to allay concerns such as the ones you have.

What do you think?

A REST binding would be great too, but in all honesty I don’t know enough about the technology to give a meaningful comment. I’m a SOAP + WS-* man. :P

]]> By: Bradley Beddoes http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-44 Bradley Beddoes Thu, 27 Mar 2008 22:56:40 +0000 http://thestateofme.wordpress.com/?p=19#comment-44 Excellent post. We've been working in this space for quite some time now on our open source ESOE project. The way we've essentially hooked up the communication is to have the PEP implementation part of a SAML 2.0 SP implementation which in turn can consume SAML 2.0 metadata and resolve exposed endpoints of the trusted PDP, certainly not *the* solution but its working for now. With the PEP and PDP interaction working quite nicely we're now moving onto developing a much nicer central PAP interface and starting to think about how we might be able to allow policy changes to occur from remote systems securely. Naturally it would be nicer if administrators don't have to leave their application of choice and goto some central PAP to update access control policies. We release everything under Apache 2 licensing so if anyone wants to take a look or help us solve some of these problems then you're more then welcome to come on over to http://esoeproject.org Excellent post.

We’ve been working in this space for quite some time now on our open source ESOE project. The way we’ve essentially hooked up the communication is to have the PEP implementation part of a SAML 2.0 SP implementation which in turn can consume SAML 2.0 metadata and resolve exposed endpoints of the trusted PDP, certainly not *the* solution but its working for now.

With the PEP and PDP interaction working quite nicely we’re now moving onto developing a much nicer central PAP interface and starting to think about how we might be able to allow policy changes to occur from remote systems securely. Naturally it would be nicer if administrators don’t have to leave their application of choice and goto some central PAP to update access control policies.

We release everything under Apache 2 licensing so if anyone wants to take a look or help us solve some of these problems then you’re more then welcome to come on over to http://esoeproject.org

]]> By: Chris Swan http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-43 Chris Swan Wed, 26 Mar 2008 17:01:10 +0000 http://thestateofme.wordpress.com/?p=19#comment-43 Craig - you're quite right that the req-resp mechanism provides the necessary semantics for allowing PEPs to talk to PDPs, and if both support XACML (a fair assumption for the time being) then we have a common vocabulary in which to ask questions and get answers. I still feel however that there's something missing at the plumbing level that prevents me from grabbing vendor A's PEP and hooking it up to vendor B's PDP. Although they both share a common vocabulary they don't know how to call each other. This could of course be dealt with by plucking a few items of the WS-* smorgasbord, with Addressing and MEX looking likely suspects. I feel however that this route quickly descends into SOA hell - it shouldn't matter that each vendor has their own WSDL for their PDP service interface because PEPs can just look it up in the service registry and dynamically bind. Clicking my heels together and returning from SOA hell to the surface world; we find that service registries don't exist, all the popular services have simple RESTian interfaces, and very late binding is acknowledged as impossible to pull off. This leaves us facing the challenge of defining something that has a simple and lightweight set of core functionality (e.g. to act as a transport for XACML req-resp) that is easy to find. Craig – you’re quite right that the req-resp mechanism provides the necessary semantics for allowing PEPs to talk to PDPs, and if both support XACML (a fair assumption for the time being) then we have a common vocabulary in which to ask questions and get answers. I still feel however that there’s something missing at the plumbing level that prevents me from grabbing vendor A’s PEP and hooking it up to vendor B’s PDP. Although they both share a common vocabulary they don’t know how to call each other. This could of course be dealt with by plucking a few items of the WS-* smorgasbord, with Addressing and MEX looking likely suspects. I feel however that this route quickly descends into SOA hell – it shouldn’t matter that each vendor has their own WSDL for their PDP service interface because PEPs can just look it up in the service registry and dynamically bind. Clicking my heels together and returning from SOA hell to the surface world; we find that service registries don’t exist, all the popular services have simple RESTian interfaces, and very late binding is acknowledged as impossible to pull off. This leaves us facing the challenge of defining something that has a simple and lightweight set of core functionality (e.g. to act as a transport for XACML req-resp) that is easy to find.

]]> By: Craig http://blog.thestateofme.com/2008/03/25/directories-20-entitlements-services/#comment-41 Craig Wed, 26 Mar 2008 12:15:20 +0000 http://thestateofme.wordpress.com/?p=19#comment-41 XACML already contains a definition for the PEP to PDP interaction - the and elements? XACML already contains a definition for the PEP to PDP interaction – the and elements?

]]>