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

[Chiusano J. <chi...@ba...>]

Thanks Seth. I should be clearer on the purpose of my request:

My request is actually for a document that I am writing for a major US
federal agency (a Web Services Standards Analysis), not for an
implementation. My aim is to provide an example of how XACML could be
used for access control with Web services, and (if possible) for
providing SAML information to XACML. So what I'm looking for is actually
an XML example - an alternative to the "charge for throughput" example
in the WSPL specification (it's a great example, just not leverageable
for my purposes).

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton

Seth Proctor wrote:
> 
> 
> > <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