Web Services Authorization

[bill_bailey]

I am starting to use Spring WS with ACEGI and although there is integration with ACEGI for authentication, I'm wondering if anyone can comment on any best practices for authorization. It seems to me that authorization could be enforced either at the URL level using standard web security OR on objects using an ACEGI method interceptor. I'm inclined to think that my best bet is to secure each of my business objects using an ACEGI method interceptor, but I'm wondering if there are other options I haven't considered. Can the ACEGI security interceptors be applied directly to an endpoint to avoid the additional work of unmarshalling the XML, etc. before returning a security violation exception?

On a related note, one of the disadvantages of the out-of-the-box methods for configuring ACEGI is that all the configuration is in XML files. This makes it quite painful when security is not always static and you need to provide user interfaces for modifying it. I implemented some time ago a rough mechanism for storing web services permissions in a database and accessing them via some custom ACEGI classes, but I was not entirely satisfied with the results.

Has anyone else done this or does anyone have comments or suggestions?

Any thoughts or comments are appreciated. Thanks in advance.

Bill Bailey
Senior Developer / DBA
Northland, A Church Distributed

[Arjen Poutsma]

Basically, there are two options for doing security in Web services. One is to use HTTP (plain or digest); the other WS-Security. The easiest is to use HTTP, because you can set that up in your web.xml. The downside of this approach is that it's pretty course-grained: each operation on the service needs the same rights.

Acegi is a bit more difficult, but also offers a lot more. For one thing, you can set authorization permissions on business service-level methods. The way you authenticate to them is completely separated, i.e. you can authenticate in a Web app, or using a Web service, and still have them same authorization backend.

Also note that WS-Security is not implemented that widely. Basically, only .NET and Java implement it; most of the other languages don't.

[bill_bailey]

Thanks. I think I will go the ACEGI method interception route. I have some experience with ACEGI already so I'm comfortable with this approach. We only intend to use the WS-Security authentication piece so I think we can manage the lack of wide support. The only language other than Java and possibly .NET would be Flex and as long as we can set the required SOAP headers with the username and password tokens, it should work, right?

Just to elaborate a little on my original question. Although I understand the benefit of placing the security on the business methods (i.e. enforcing the security in a central reusable location), I thought it might be possible to for example place an interceptor on the endpoint itself (e.g. based on a SOAP action) rather than on the business object methods. My thinking was that enforcing the security on the business methods would mean all the endpoint processing (e.g. parsing the XML, unmarshalling it, etc.) would still have to happen even when the request would eventually be rejected for security reasons. If the security check happened on the 'other side' of the endpoint this would not be the case. But I guess that would also mean less reuse of the security configuration if the same business methods were invoked from other places OR you would have to have security in both places.

Am I making any sense? At this point, the business method interceptors are fine for my purposes, but I'm interested in your thoughts on this.

Thanks again.

Bill

[Arjen Poutsma]

Thanks. I think I will go the ACEGI method interception route. I have some experience with ACEGI already so I'm comfortable with this approach. We only intend to use the WS-Security authentication piece so I think we can manage the lack of wide support. The only language other than Java and possibly .NET would be Flex and as long as we can set the required SOAP headers with the username and password tokens, it should work, right?

Right.

Just to elaborate a little on my original question. Although I understand the benefit of placing the security on the business methods (i.e. enforcing the security in a central reusable location), I thought it might be possible to for example place an interceptor on the endpoint itself (e.g. based on a SOAP action) rather than on the business object methods. My thinking was that enforcing the security on the business methods would mean all the endpoint processing (e.g. parsing the XML, unmarshalling it, etc.) would still have to happen even when the request would eventually be rejected for security reasons. If the security check happened on the 'other side' of the endpoint this would not be the case. But I guess that would also mean less reuse of the security configuration if the same business methods were invoked from other places OR you would have to have security in both places.

Ok I see you point. But understand that WS-Security requires the XML message to be parsed entirely anyway, mostly due to signing/encryption requirements. There's no way to do WS-Security in a streaming fashion, so it is always relatively slow.