views:

205

answers:

3

Hi all,

I'm after some guidance on how to approach coding a problem, I don't want to jump straight into coding without think about it as I need it to be as generic and customisable as possible,

The scenario is i have a web service that acts as a gateway to downstream services, with the aim of authenticating and authorising SOAP message destined for down stream services, basically allivating the downstream service from doing it themselves. Each SOAP message has a variety of different WS-Security mechanisms attached usually a WS-UsernameToken, WS-Timestamp, and a XML Signature of the message body.

My problem is i want to figure out a good extensible way of validating all these security mechanims, I'm not after how to do it just how to appraoch it.

I thought about having a controller class that is intialised and controls the validation flow i.e.

ISecurityController controller = SecurityControllerFacotry.getInstance();
boolean proceed = controller.Validate(soapMessage);

using it very much like a template design pattern which ditates the flow of logic i.e.

public Boolean Validate(Message soapMessage)
{
 return ValidateAuthentication(soapMessage) && ValidateTimeStamp(soapMessage) && ValidateSignture(soapMessage);
}

Would this be the best apporach to the problem?

Also would it be best to put these validation methods each into a class of there own that which implemented a common interface? So that a class could be instantiated and retrieved from some sort of validation factory i.e.

IValidationMechanism val = ValidationFactory.getValidationType(ValidationFactory.UsernameToken);
boolean result = val.Validate(soapMessage);

This would give me an an easily extensible aspect.

Would this be an vaible solution or can anyone think of other ways of doing it?

I'm interset in design patterns and good oo principles so would like to go down a route utilising them if possible.

Thanks in advance

Jon

EDIT: The service is basically a gateway security service that relieves the burden of authentication and authorisation from services that sit behind it. The security service can be thought of as an implicitly invoke intermediary on the SOAP message path that validates the security mechanisms in the SOAP message and depending on the validation result forwards the message to the appropriate down stream service by interrogating the WS-addressing headers. Although the service is not really the question it is more on how to implement the validation procedure.

+2  A: 

I think your intuition on this is good; go with the single interface approach. That is, hide your validation implementations behind a single validation interface; this allows you to extend your validation implementations later without modifying the calling code.

And yes, the idea of putting the validation into its own class is a good one; you might want to think about having a common base class, if you have any common validation items (for example, username might be a common validation element, even though each different validation scheme may encode it differently; one as an element, another as an attribute, etc.). I think validation classes is a more appropriate mapping for the level of complexity that you're talking about anyhow, as opposed to validation methods; I suspect that the type of validation you're doing requires groups of methods (i.e., classes).

McWafflestix
your right the validation mechanism would require a gourp of methods. Do you then think it appriopate to retrieve the validation classes from a factory?
Jon
I think that factory use is perhaps appropriate, depending on your implementation; even then, though, I think the factory use should be hidden behind a single Validate() request. This allows you to extend the factory implementation (by changing the factory, etc.) transparently to the calling code.
McWafflestix
+1  A: 

I can think of another way to validate your SOAP message against different validations. You use a visitor Pattern.

For that You will have a simple wrapper around the SOAP message you get.

     MySoapMessage{
         SOAPMessage soapMessage;
         List<String> validatonErrors;

        void accept(Validator validator){
           validator.isValid(this);
}
         }

Your security Controller will contain the list of Validatiors which you will inject basically.

     SecurityController{
        List<IValidator> validators;

        //Validate the message
       void validate(MySOAPMessage soapMessage){
        forEach(Validator validator: validators){
         soapMessage.isValid(validator)
             }
        }  
  }

Your Validators will look something like this.

UserNameValidator implements IValidator{
public void validate(MySOAPMessage message){
// Validate and put error if any
}

}

You dont need and unnecessary factory here for the validators.. if you want to want to add/remove validators from the controller you just inject/un inject then from the list.

Pratik
This is an excellent idea, i will give it a go, I like the simplicity of it not need factorys. thanks!
Jon
+1  A: 

Spring has a generic validation package that handles this type of process nicely IMHO.

Theirs looks something like

public interface Validator {
    public boolean supports(Class<?> clazz);
    public void validate(Object o, Errors errors);
}

Granted, they're using an Errors param to return validation issues in, which might or might not suit your goal.

ptomli
I like this approach having an error holder i think would be appropiate in my case.
Jon