Re: [sunxacml-discuss] XACML: Access Control for Web Services

[Seth P. <set...@su...>]

 
> <Quote2>
> For now I'll assume you're asking about using X.509 certs within a
> policy. Please correct me if I'm wrong :)
> </Quote2>
> 
> That's correct.

Out of curiosity, do you really need this feature? I assume you're using
certificates for some initial authenitcation, but will you have policies that
use the certificate? It might be that you don't need the certificate as part
of the authorization decision. It might also be that you only ever need a
few fields, in which case your PEP might strip out these values and include
them in the Request using standard datatypes. Just wanted to bring this up
since it might help simplify things.
 
> <Quote3>
> It would be fairly easy, however, to define a new datatype for X.509
> certs, and then define some new functions to access particular fields.
> If you're interested in going into this example in detail, let me know
> and I'll walk you through it.
> </Quote3>
> 
> Yes please - that would be great.

I know I promised detail, but I'm a little strapped for time right now, so
this will be a little thin :) Still, it should give you what you need (assuming
you really need full X.509 support within your policies).

XACML lets you define new datatypes, and new functions that can operate over
those datatypes. What you first need to do is define a new datatype for X.509
PKCs. Using the open source code, you extend the AttributeValue class as a
starting point. This class needs to be able to parse and encode the
certificate. You'll also need to define some URI to identify your datatype
(this can be just about anything, though it should not be in the XACML TC's
namespace). Internal to your new class you can use any representation for
your certificate, like the classes provided in java.security.cert.

Now that you have support for your new datatype, add a proxy to the
AttributeFactory class and you can now support X.509 certificates as a
datatype in your Requests or in finder modules. You won't be able to do
anything with the PKCs just yet since the standard functions don't know
how to operate on your datatype. So, for each operation you want to support,
you need to write a new Function (either implement the Function interface
or take advantage of the FunctionBase class). These functions might be
supporting one specific action, or might be general accessor methods. 

That's about it. I don't know what exactly you want to do with your PKCs
in your policy (are you checking for cipher type? issuer DN? policy
constraints?), so I don't know for sure what kinds of functions you need.
Like I said above, it may be sufficient to strip out some values ahead
of time and use standard datatype and functions, which would require less
work.

> <Quote4>
> there's no standard way to provide the SAML info to XACML, but it's
> certainly doable, and it's fairly straightforward. I know several people
> have done this. Again, I'm happy to provide examples if this is what
> you're asking.
> </Quote4>
> 
> Yes please - that would be great as well.

In this case, you're probably going to take the approach of pulling out SAML
attributes and placing them in the request to the XACML PDP (or returning them
from AttributeFinderModules). This is just a matter of transforming from the
SAML forms to the XACML forms for standard attributes. If you're in an
environment where you're using both SAML and X.509, this makes it even more
likely that you don't want to actually include a PKC in your request, since
providing infividual fields gives you a generic way to support both SAML
and X.509.

Is all that clear? Is it helpful?


seth