In my previous blog post : integrating flex 3 with spring security I made a good effort to create a nice flex 3 application and integrate authentication and authorization with spring security. A few days a go I received a trackback from sven. Curious as I am I started reading the material he [...]]]>

In my previous blog post : integrating flex 3 with spring security I made a good effort to create a nice flex 3 application and integrate authentication and authorization with spring security. A few days a go I received a trackback from sven. Curious as I am I started reading the material he provided and especially the other links he mentioned. That made me think about my own solution. To be honest I think I did not really do a good job. It works, but still not optimal for most of the flex situations.

In my previous post I already mentioned the problem of sessions that are closed and exception handling with respect to security. In this article I am looking at the available mechanisms for security in flex. In this post I explain why I am not really using the flex or better BlazeDS security mechanisms and what you probably should use them for.

If this made you curious enough, read on. If you have questions, remarks or improvements, do not hesitate to use the comments feature of this blog item.

The security problem

The basic problem: we want to know who you are and we then what you are allowed to do. In other words, we want to use authentication to determine if you are who you say you are and authorization to determine what you are allowed to do. For web applications, authentication is a territory that is well known. There are lot’s of different ways to determine if you are who you say you are. Think about password, iris scan, finger print, tokens, etc.

When clients are becoming richer or fat, this does not have to change, but if you are creating applications that should function offline as well, you have some limitations. For my sample I am using a username/password combination. I am not using https, not using encryption. It is a basic sample.

I am going to show you a possible solution that uses some basic components to authenticate against a server side web application. Using BlazeDS we are talking direct to spring beans that are secured using spring security.

Flex and BlazeDS security mechanism for remoting

BlazeDS has a few things that can help you to secure the remote calls from the web client. You can configure security for remote destinations. This way BlazeDS makes sure you have been authenticated and have the required role. The following piece of code gives an example of a destination that is secured. The destination references a security-constraint that is also presented in the code.

<destination id="bookManager">
    <properties>
        <factory>spring</factory>
        <source>bookManager</source>
    </properties>
    <security>
        <security-constraint ref="trusted"/>
    </security>
    <security-constraint id="trusted">
        <auth-method>Custom</auth-method>
        <roles>
            <role>ROLE_USER</role>
        </roles>
    </security>
</destination>

This way the user is asked for a username/password using for instance using Basic authentication. This mechanism makes use of the application server. Since not all application servers use the same mechanism for authentication there are special implementations available for a number of application servers. If you want to use an application level authentication you need to create a custom LoginCommand.

At first I thought this was the way to go, to be honest I never really understood it. So maybe I am missing something. For now I think my solutions is more flexible and easier to understand for an average java programmer. Therefore the flex/BlazeDS model was not the way to go for me. Let’s go over to a general view of my solution.

Overview of my solution

I am a java programmer coming to the flex world. Therefore my solution might be a bit to java-ish. Since I am integrating with java and spring security specifically, I do not really mind. The following things were important to me when creating the solution:

• No double configuration of roles for authorization, but the flex application must have the availability of obtained authorizations.
• Easy recovery in case of exception due to bad credentials, unauthorized access of remote methods, session time out, etc.
• No necessity for offline working (no authentication details available in the client)
• Possibility of re-authentication in case of a session time out without asking for credentials again.

This all can be done using some hierarchy in classes, use of singletons for user data and custom events. The following image gives a schematic overview of the solution. You are missing the actual pages: Home and AuthenticationForm. You are also missing the actual service implementations on the server side. Both topics will be talked about later on.

Remote services, error handling and events.

The image shows the main components for authentication and authorization from the flex side. The yellow classes are provided by the framework, the green ones are services that interact with remote services and the data obtained from the server. The blue ones are the events used by the security mechanism to expose the results of authentication and authorization requests.

Let’s start with the services. The super class RemoteService contains some generic methods for catching and translating them into events. The constructor excepts an id and the name of the destination for the RemoteObject to create. Beware that this name should be the same as configured in the destination of the remoting-config.xml. The next block of code shows you the implementation of this RemoteService

/**
 * Super class for all remote services that contains some generic methods.
 */
public class RemoteService {
    private static var BAD_CREDENTIALS:String =
            "org.springframework.security.BadCredentialsException : Bad credentials";
    protected var remoteObject:RemoteObject;

    /**
     * Constructor accepting an id and destination for the actual RemoteObject to create. An event listener
     * is added for exceptions.
     * @param id String representing the id of the new RemoteObject to create
     * @param destination String representing the destination of the RemoteObject to create
     */
    public function RemoteService(id:String, destination:String) {
        this.remoteObject = new RemoteObject(id);
        this.remoteObject.destination = destination;
        this.remoteObject.addEventListener(FaultEvent.FAULT,onRemoteException);
    }

    /**
     * generic fault event handler for all remote object actions. based on the received message an action
     * is taken, mostly throwing a new event.
     * @param event FaultEvent received for handling
     */
    public function onRemoteException(event:FaultEvent):void {
        trace('code : ' + event.fault.faultCode +
              ', message : ' + event.fault.faultString +
              ',detail : ' + event.fault.faultDetail);

        if (event.fault.faultString == BAD_CREDENTIALS) {
            Application.application.dispatchEvent(
                    new AuthenticationFailureEvent(AuthenticationFailureEvent.AUTHENTICATION_FAILURE,
                            "problem while authenticating"))
        } else {
            Application.application.dispatchEvent(
                    new RemoteExceptionEvent(RemoteExceptionEvent.REMOTE_EXCEPTION,
                            "unknown problem occurred during a remote call : " + event.fault.message));
        }
    }
}

The onRemoteException is not finished yet, at the moment we only handle BAD_CREDENTIALS differently than other exceptions. I can imagine that we will have more exceptions here. But for now the structure is clear. Most important to notice is the use of events. Using the special Application object, we dispatch the AuthenticationFailureEvent as well as the RemoteExceptionEvent. The next thing is to create a sub-class of this service that actually uses the connection. So let’s have a look at the SecurityService

The SecurityService is used to authenticate a user making use of the provided username and password. The following block of code contains the implementation if this method:

public function authenticatePrincipal(username:String,password:String):void {
    var userData:UserData = UserData.getInstance();
    userData.username = username;
    userData.password = password;
    remoteObject.authenticatePrincipal.addEventListener(ResultEvent.RESULT,handleAuthenticatePrincipal);
    remoteObject.authenticatePrincipal(username,password);
}

Important in this piece of code is obtaining the singleton UserData instance. This instance contains the credentials and has some utility methods to see if the logged in user has administrative rights or is a plain user. The way to get the results back looks a bit strange to the average java programmer, but we are doing a-synchronous calls (like JMS guys). The next piece of code gets called if the response is received and handles this response.

protected function handleAuthenticatePrincipal(event:ResultEvent):void {
    var userData:UserData = UserData.getInstance();
    userData.authenticated = true;

    var obj:Object = event.result;
    var obtainedRoles:Array = obj.roles as Array;
    for(var i:int=0; i < obtainedRoles.length; i++) {
        userData.addGrantedRole(obtainedRoles[i])
    }

    Application.application.dispatchEvent(
            new AuthenticationEvent(AuthenticationEvent.AUTHENTICATION,"user is authenticated"));
};

As you can see in the code we tell the userData object that he is authenticated now and we add the roles he is authorized for. To make sure that those that are interested get notified of the authentication we throw an event.

The next step is to actually start the authentication process. This is done on the visual components. The first one that gets loaded is the Home.mxml page.

Visible components interacting with services

To demonstrate the complete authentication process we need only two visual components: Home.mxml and AuthenticationForm.mxml. I am not going to show them completely, you can browse the sources only. (see references at the bottom). In Home.mxml we add listeners for the AuthenticationEvent as well as the RemoteExceptionEvent, then we create the form and add it to the main content panel. The following piece of code shows just that:

private function initializeApplication():void {
    Application.application.addEventListener(AuthenticationEvent.AUTHENTICATION, handleAuthenticationEvent);
    Application.application.addEventListener(RemoteExceptionEvent.REMOTE_EXCEPTION, handleRemoteExceptionEvent);
    authenticateUser();
}

private function authenticateUser():void {
    myMainContentPanel.removeAllChildren();
    var authenticationForm:AuthenticationForm = new AuthenticationForm();
    authenticationForm.securityService = authenticationHelper;
    myMainContentPanel.addChild(authenticationForm);
}

As you can see in the code we call the method handleAuthenticationEvent when a user gets authenticated. This method is not interesting for our cause, it could just show Yes, I am authenticated in an alert box. Let’s have a look at the AuthenticationForm now. This is also a pretty simple class with a call to the security service and a method that handles the a-synchronous callback.

private function submitLogin():void {
    submitButton.enabled = false;
    Application.application.addEventListener(
            AuthenticationFailureEvent.AUTHENTICATION_FAILURE,loginServiceFaultHandler);
    securityService.authenticatePrincipal(userName.text,password.text);
}

private function loginServiceFaultHandler(event:AuthenticationFailureEvent):void {
    authenticationMessage.text = "Problem while authentication ...";
    authenticationMessage.visible = true;
    submitButton.enabled = true;
}

As you can see, the AuthenticationFailureEvent is handled by this form page. We show just a text that there was something wrong. In any other cases we let the Home page catch the AuthenticationEvent, we do nothing here.

Final part to cover is the server side implementation. That is what we’ll do next.

Server side implementations of remote services

Within the remoting-config.xml I have configured the following destination:

<destination id="authenticationHelper">
    <properties>
               <source>nl.gridshore.samples.books.web.security.security.AuthenticationHelper</source>
    </properties>
</destination>

Within the class Authenticationhelper you can find the following method that obtains the spring application context, executes the authentication and handles the obtained principal. Take notice of the name of the bean we obtain. This is the default name when using the namespace configuration of spring-security. The other important part is the creation of the UsernamePasswordAuthenticationToken and doing the actual authentication. Problems with authentication result in a runtime exception that is propagated into flex and handled by the RemoteService object.

public AuthorizationData authenticatePrincipal(String username, String password) {
    ApplicationContext appContext = WebApplicationContextUtils.getWebApplicationContext(
            flex.messaging.FlexContext.getServletConfig().getServletContext());
    AuthenticationManager manager = (AuthenticationManager)appContext.getBean("_authenticationManager");
    UsernamePasswordAuthenticationToken usernamePasswordAuthenticationToken =
            new UsernamePasswordAuthenticationToken(username,password);

    Authentication authentication = manager.authenticate(usernamePasswordAuthenticationToken);
    SecurityContextHolder.getContext().setAuthentication(authentication);

    GrantedAuthority[] authorities =
            SecurityContextHolder.getContext().getAuthentication().getAuthorities();
    int numAuthorities = authorities.length;
    String[] grantedRoles = new String[numAuthorities];
    for (int counter = 0; counter < numAuthorities ; counter++) {
        grantedRoles[counter] = authorities[counter].getAuthority();
    }
    String name = SecurityContextHolder.getContext().getAuthentication().getName();
    return new AuthorizationData(grantedRoles,name);
}

That is about it, if you feel this is the way to go, check the sources in my google code repo. If you have strong opinion that this is just wrong, please share your thoughts.

References

• Google code project (browse to books-overview)
• Mind the flex by sven
• Integrating flex 3 with spring security (formerly known as Acegi)

In [...]]]> There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your data, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?

In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

In part 1 , I’ve dealt with Username Token authentication, an easy to use way to provide an authentication mechanism for your web service.

In part 2 , I have described Transport Layer Security (TLS) -formerly known as Secure Socket Layer- and message encryption.

In this part, the last one in this series, I will explain how the the digital signature can provide some form of security in web services.

Lets recap the security requirements I have discussed in my introduction .

1. The client must be sure it sends it messages to the correct provider;
2. The provider wants to be sure that the client is authorized to;
3. The provider wants to be sure that the client is who it says it is;
4. Both the consumer and provider want to be sure that the messages can only be interpreted by each other;
5. Both parties want to be sure that the message sent is received unchanged.

So far, we have dealt with the first four requirements by implementing Encryption or TLS/SSL or by requiring a UsernameToken from the client. But until now, we are still not the guaranteed that the messages are unmodified since we’ve sent them.

Encryption will prevent modification during the transport between the sender and the final recipient, the one with the private key to decrypt the message. However, once decrypted, the message is free to be modified.

Digital invoices are an example of documents that should be digitally signed. In some countries (in The Netherlands in any case) the Belastingdienst (Tax authority) requires that all digital invoices are digitally signed by the company sending the invoice. This way, the Belastingdienst is able to verify who sent the invoice -the one who signed it- and be sure that it hasn’t been tampered with in the meantime. Of course, the company receiving this invoice wouldn’t really mind to have these guarantees too, I suppose.

Now that we have a real valid use case and are really convinces of the need of the digital signature, let’s have a look at how it works.

Actually, it is almost identical to encryption, but then in the opposite way. With encryption, the message is encrypted using the public key. Only the one with access to the private key can decrypt it. When signing, the private key is used to sign the message, and the public key is used to check the signature. Since access to the private key is limited to authorized people/machines, only they can sign the message. Anyone can access the public part of the key -hence “public”-, meaning that anyone can check the signature.

When a message is signed, the actual message itself is not encrypted. That wouldn’t be very meaningful, because that would mean that anyone would have to decrypt the message, even though they might not really care about the signature. Instead, a hash is creating from all the parts that have to be signed. That hash is then encrypted using the private key. The encrypted has is then inserted in (the header of) the message. Typically, one would also include the public key, to allow anyone to check your signature. That’s it.

To check a signature, the hash is recreated the same way as it was done originally and the encrypted hash from the signer is decrypted. If the message has not been tampered with, the newly generated hash and the decrypted original hash are identical. If they are different, you know the message has been tampered with.

The signature on the message will ensure the reader that the message has not been modified since it has signed sent and that the contents were created by, or created with the consent of, the user who signed it. If you want to see it in action, you can download the example code from the Gridshore google code repository. The demo uses all three forms of security described in this series.

This concludes this three-part article about web service security. The type of security you would choose for your web service clearly depends on the needs of your specific service. UsernameToken provides for an easy to use authentication mechanism, while TLS or message encryption prevents a third party from reading the messages. Finally, the digital signature will ensure that a message is not modified after it is signed.

In [...]]]> There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your data, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?

In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

In part 1 , I’ve dealt with Username Token authentication.

In this article, I will describe Transport Level Security (TLS), formerly known as Secure Socket Layer and message encryption.

Lets recap the security requirements I have discussed in my introduction.

1. The client must be sure it sends it messages to the correct provider;
2. The provider wants to be sure that the client is authorized to;
3. The provider wants to be sure that the client is who it says it is;
4. Both the consumer and provider want to be sure that the messages can only be interpreted by each other;
5. Both parties want to be sure that the message sent is received unchanged.

Transport Level Security

Using “Transport Level Security” (TLS), formerly known as Secure Socket Layer (SSL), and also referred to as HTTPS, will take care of requirements 1 and 4.

TLS is a technically very complex algorithm, with a lot of varieties. Fortunately, the general concept is not as hard to grasp. It works as follows:

1. The client will send a “Hello” to the server.
2. The server will response with a “Hello”, and send a certificate to the client
3. The client will decide whether it trusts the server’s certificate
4. The client will use the servers certificate to encrypt its own certificate and send it back to the server
5. Depending on the exact algorithm chosen, the client and server will exchange some more encryption information to make the communication “water tight”.

If you really want to know the technical details of TLS, have a look at this page: http://an.wikipedia.org/wiki/Secure_Sockets_Layer. For the typical Web Service developer, these details are not really important. However, knowledge of how the first three steps work can help you prevent a lot of problems.

Especially step 3 is of great importance. The client has received a certificate from the server, and has to decide whether it is safe. This decision is based on a few factors.

First of all, the certificate has to have been issued for the domain that has been requested. So if you access a service on http://somecompany.com/service and get a certificate issued for someothercompany.org, the client will reject the certificate. Some clients, such as web browsers allow the users to override this decision and accept the certificate anyway. A web service client doesn’t typically have a user, so there is no room for second chances.

Secondly, the certificates timestamp has to be valid, meaning that it hasn’t reached it’s expiry date yet. Depending of the type of certificate, it is valid from 1 to tens of years.

The third requirement can sometimes give some problems: the client has to trust the certificate. This can best be explained using a real life example. Imagine yourself at the border control on a foreign airport. If you show them a paper with your name and a signature on it, chances are small that they let you through? Why? Because they can’t trust a self-signed certificate, or one that is signed by a relative. However, if that same name is written on a legal passport, given and signed by your country’s authority, border control will trust it, because they trust them. In TLS, it is exactly the same.

If you order a certificate from a certificate authority (CA), nobody will actually know that you have that certificate. And you don’t trust what you don’t know. However, you have paid the CA to sign your certificate. And maybe the CA certificate has been signed with yet another certificate. Now, if you trust the CA, you will automatically trust all certificates that have been signed with that CA. Back to our border control. If you trust the US government to issue correct passports to people, you will automatically trust all passports of US citizens, even if you don’t know that person.

To mark a certificate as trusted, the certificate has to be stored in a so-called “trust store”. Your browser has a truststore that includes the large CA certificates by default. Just look around in the configuration of your browser. You’ll be able to install other certificates if you like. For example, one that you have created and signed yourself.

You can also configure a truststore for your web service client. By default, your JVM will probably include the large CA certificates, such as Verisign and Thawte. If you’re running on an application server, chances are big there is a trust store configured in them, too. Of course, you can override the truststore by defining your own.

Ok, now that we’ve seen a lot of misery on the client side, let’s have a look at what has to happen on the server side. Well, luckily, not all that much. All you have to do is configure your web server to use SSL. Somewhere along the line it will require you configure a certificate to use. And since you probably want to be trusted, make sure to have your certificate signed by a large CA.

The good part is that all communication between client and server is encrypted in such a way, that only these parties are able to read the messages. And, as a bonus, the client is ensured that it is really talking to the server it was expecting to communicate with.

Message encryption

TLS is nice, but if you have a message that will pass a few endpoints, or has to be logged in the mean time, it doesn’t really help you. If you have to keep your data secure after is has arrived at your first endpoint, message encryption could be your solution.

Let’s start off with an example. Let’s image we have a service where consumers can place orders. Just for the sake of the example, the request will first be processed by an endpoint that checks the stocks. If the stocks are sufficient, the payment is processed. If TLS were used between the consumer and the first endpoint, the message would be sent unencrypted. Of course it is possible to encrypt that communication too, but that would probably be a performance hit.

The idea behind encryption is not really complex. The entire message, or part of it is encrypted using the public key part of the certificate. Since the private key is required to decrypt it, only the recipient (or at least only systems with access to the private key) will be able to so. Even if a message is stored for future reference, the contents will be unreadable to any third party.

Typically, only parts of messages are encrypted. You could think of elements containing payment information or other private contents, such as social security numbers. The example project in go ogle code shows an example of a message where an ID is encrypted. Not a really powerful use case, but it shows how the technology works.

As with TLS, message encryption will deal with items 1 and 4. However, it will only do so for the parts of the message that have been encrypted.

Conclusion

Both TLS and message encryption give the communication between consumer and provider some form or privacy and protection against eavesdropping. If configured correctly, they can work transparently to the implementation of both the client and the consumer, but will claim some of your performance.

My next and last article in this series will discuss message signing, which will deal with the security item that hasn’t been covered yet: “Both parties want to be sure that the message is received unchanged”.

There seems to be a lot of misunderstanding about Web Service [...]]]> Recently, I’ve been helping a customer with some Web Service issues. One of the problems was their limited knowledge of security in that area. He asked me to explain, in Jip and Janneke language [1] how SSL works and what it actually secures.

There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your services, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?

In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

This article will go more in-depth in the Username Token authentication.

First, I’ll list the 5 security requirements we usually have to feel really secured. These have been treated in the introductory post in this series.

1. The client must be sure it sends it messages to the correct provider;
2. The provider wants to be sure that the client is authorized to;
3. The provider wants to be sure that the client is who it says it is;
4. Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
5. Both parties want to be sure that the message sent is received unchanged.

The username token will take care of items 2 and 3. The username token is typically a security header in the soap message from the client towards the server. This header contains a username and a password, in one form or another.

In the simplest form, a UsernameToken authentication header contains an element with a username and one with a password. This is the “PasswordText” option of the UsernameToken. When you send this message unencrypted, anyone would be able to read your username and password, an log in on your behalf. Encrypting the communication will solve this risk. However, if the message has to pass several endpoints and one of the connections in unencrypted, your password is open again, despite effort to secure it.

To prevent giving away the username and password combination for free, it is possible to use the “PasswordDigest” version of the UsernameToken. This will actually pass a hash of your password, instead of the password itself. This prevents malicious ears from plucking you password off the wire.

However, although the password is encrypted and unknown to any third party, that third party could log log in by copying the entire security header. After all, if one client can get in using that header, any client could. To prevent this, a Nonce and/or a Timestamp are made part of the hash too. The Nonce is a random value, chosen by the client. The Timestamp is the date and time the password was hashed.

So how does this prevent another user from replicating your authentication header? Well, if a Timestamp is used, the server could require that that timestamp may not be older than for example 5 minutes. This still gives the third party a 5 minute window to abuse your password. That’s where the Nonce comes in. The server can (and should) require that the Nonce may be used at most one time. If the same header -and thus the same nonce- is sent again, the UsernameToken is refused based on a duplicate nonce.

In the end, the security header could look like this:

<wsse:Security xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd” SOAP-ENV:mustUnderstand=”1″> <wsse:UsernameToken xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd” wsu:Id=”UsernameToken-33083972″ xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”> <wsse:Username xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”>username</wsse:username> <wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest” xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”>Zb5nkZdaXM3hH/bVPQRdMdYSbdo=</wsse:password> <wsse:Nonce xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”>hHDHOSh3akTwwZFs+6o13A==</wsse:nonce> <wsu:Created xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>2008-05-20T19:00:06.937Z</wsu:created> </wsse:UsernameToken> </wsse:Security>

So, does this make us absolutely secured from any attacks? Well, the likelyhood of anyone abusing your security header is very slim, but nowhere near to zero. Hackers keep lists of commonly used passwords and can use these lists to guess your password. They will see which passwords will create the given hash using the Nonce and Timestamp you have provided. It is therefore very important to generate a password instead of choosing one which is easy to remember. Why would you anyway, a client is usually a piece of software that doesn’t really have difficulties remembering any password. It is of course still not water tight, but it is more likely that the service won’t exist anymore by the time the password has been guessed.

Another way to minimize the chance of abuse of your credentials is by encrypting the messages, or parts of it. This shall be treated in my next post in this series.

The configuration of UsernameToken security in your WebService is fairly simple. Both in client and server only little configuration is needed. There are libraries that can assist you in setting up security, such as Apache’s WSS4J and Sun’s XWSS. If you want to see these libraries at work, make sure you download the code samples for this series on the Gridshore code repository: http://code.google.com/p/gridshore/source/checkout [1].

If you want to go into a little (or a lot) more technical depth of the UsernameToken specification, make sure you read the OASIS WSS specification from http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss#technical.

This concludes this post about the UsernameToken. In my next post in this series, I will shed some light on Transport Level Security and Message Encryption.

There seems to be a lot of misunderstanding about Web Service [...]]]> Recently, I’ve been helping a customer with some Web Service issues. One of the problems was their limited knowledge of security in that area. He asked me to explain, in Jip and Janneke language [1] how SSL works and what it actually secures.

There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your data, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?

In this article, I’ll explain the different methods of securing your Web Services, how each of the methods work and what you actually secure by applying each method.

First, let’s start with a definition of security. Wikipedia describes it as: “Security is the condition of being protected against danger or loss” [2]. This just means that you don’t want anyone stealing your data (expecially during transportation) or doing something unwanted with it. To feel secure in the Web Services area, we want to be assured of the following:

1. The client must be sure it sends it messages to the correct provider;
2. The provider wants to be sure that the client is authorized to;
3. The provider wants to be sure that the client is who it says it is;
4. Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
5. Both parties want to be sure that the message sent is received unchanged.

I will briefly explain each of these items.

Let’s start with the first item. The client is the one initiating the connection. Typically by accessing a URL. For example, http://services.somecompany.com/someService. However, messages towards this endpoint are routed through many routers, switches and proxy servers around the internet. How can you be sure that your messages don’t end up in the servers of “some competiting company”?

On the other side of the connection we want a similar kind of ensurance. How can you be sure that the message comes from a client that has been authorized to access that service? And how do you know the message really comes from that client and not from someone pretending to be an authorized client? Quite often, the use of services is paid for, and you’d want to be sure that nobody is using your services without paying for it.

Regarding the fourth item, just imagine sending a request to a web service provider with an order. That order will probably contain some order items, an address and payment information. If anyone can read that information, it is only a matter of minutes before the credit card number has been abused. We want to be absolutely sure that only the client and the server are aware of the contents of the messages.

And finally, if a message has been tampered with, we want both the client and the server to be able to reject that message. After all, when sending the order again, we wouldn’t want our competitor to intercept the message, change the delivery address to their own (although that would be really easy to trace for law enforcement) and forward the message to the service provider. In some countries, at least in The Netherlands, the tax authority requires that digital invoices are signed by the sender using a trusted digital certificate.

There are several tools, methods and libraries available to achieve one or more of these goals. In my next articles, I will elaborate more on the following topics:

1. Username Token authentication,
2. Transport Level Security and Message encryption,
3. Digital signing

[2]http://en.wikipedia.org/wiki/Security

This [...]]]> This blog item show a way of doing security, after some additional experience I consider this method as being non optimal. The server side does not change a lot (spring security configuration), but the client does. I explain my current solution is this blog post:Integration spring security and flex 3 the sequel/

This article is actually about two things. It explains the basic steps to use the new spring security version 2 library in a java (web) application. I am going to show the basic configuration as well as web resource authorization and bean methods authorization. The other part is the integration of flex with spring security. I am going to show how to use authentication from within flex 3 using the spring security back end. After that I’ll show a service used from within flex through blazeds to ask for the roles a logged in user has. Using these roles I am going to hide buttons to actions non admin users must not use. Like the create new book.In short this article shows the complete picture of an application using flex 3, blazeds, spring security to authenticate users and authorize actions.

Read on if you want to learn about the integration of these frameworks.

Introduction

For a lot of my applications up till now I have used Acegi or spring security to take care of authentication and authorization. So the whole idea of securing certain url’s, presenting a login form, going to a database or ldap or whatever, checking password and obtain the roles a certain user has. This has become common through out all my jsp based web applications. Now I am moving into the flex domain. I have created an application that you can use to store all your books and browse through them. Now I want to make sure that not everybody can see the application, and only special users can insert and update books. Just because I know how to handle springframework at the server side, it seems logical to keep it that way. I have already written about the integration of flex and spring, now I want to reuse my security knowledge to secure my flex application.

One warning before you think this solutions solves all your problems. Please check the future directions, there are some differences between a normal web application and flex application in relation to session management and probably some other things as well.

So what do we need to do, let’s have a birds eye view over the complete solution:

• change the pom
• add a filter to your web.xml
• Configure the filter chain using the excellent new spring security namespace support.
• Configure the resources to secure (at first all)
• Fine tune the resources to secure, only *.html so everybody can download the flex swf file
• create the login form in flex, including the remote call and the event handling of the result.
• Implement method level security
• Create a remote call that returns the roles for an authenticated user
• Use the obtained roles to prevent showing the button to open the new book form.

Enough has been said, let’s start configuring the basic security. If you want to have a look at the source code, go to my google code project @ http://code.google.com/p/gridshore. Check the books-overview project.

Configuring Spring security (authentication and resource authorization)

First the changes in the pom file, we exclude the spring-support jar, this is important since we use spring 2.5.x and that version does not contain the spring-support module anymore. This results in some jars from spring 2.0.x due to the dependency from spring-security.

    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-core-tiger</artifactId>
        <version>2.0.0</version>
        <exclusions>
            <exclusion>
                <groupId>org.springframework</groupId>
                <artifactId>spring-support</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

That takes care of the needed jars on the classpath, now can actually start by adding a filter including mapping to the web.xml. If you look at the filter-mapping, you can see we pass everything to the spring security filter. This gives flexibility to the actually secured resources, but you can optimize it a bit.

    <filter>
        <filter-name>springSecurityFilterChain</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>springSecurityFilterChain</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Next step is to implement security, the following lines of code secures all web resources and creates an in memory user store with two users. As you can see in the code, there is almost nothing to configure. Spring security makes use of a lot of sensible defaults. You do not even have to configure your own login screen. There is even a default version for that as you can see in the image after the code.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:security="http://www.springframework.org/schema/security"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
       http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.xsd">
    <security:http auto-config="true">
        <security:intercept-url pattern="*" access="ROLE_USER"/>
    </security:http>
    <security:authentication-provider>
        <security:user-service>
            <security:user name="admin" password="admin" authorities="ROLE_USER, ROLE_ADMIN"/>
            <security:user name="user" password="user" authorities="ROLE_USER"/>
        </security:user-service>
    </security:authentication-provider>
</beans>

Now we can prevent people from downloading he swf file, could be a nice security thing, but not really what I want. I do not really care if they can download the swf, I care more about consistent look and feel and having some good authentication. Next step is to create the login form in the flex app.

Configure flex to use spring’s authentication

First we have to change the resources that are secured.

    <security:http auto-config="true">
        <security:intercept-url pattern="index.html" filters="none"/>
        <security:intercept-url pattern="*.swf" filters="none"/>
        <security:intercept-url pattern="*.html" access="ROLE_USER"/>
    </security:http>

Now that we have that out of our way, let’s have a look at the flex code. The Home.mxml is the application that gets started. First a public parameter called authorization, this parameter is of our on type AuthorizationControl and contains the username as well as the granted roles. Making this parameter public enables all other flex modules to ask for the value. Another function that is public and important for the same reason is the function isAuthorized. This returns false if the current user has not been authorized yet. After the screen has been created and is ready to be displayed we create the login form using the creationComplete event. The following function is called to create the login form and add it to the page. As you can see, we remove all the children of the main content panel before we add the login form.

    public function authenticateUser():void {
        myMainContentPanel.removeAllChildren();
        myMainContentPanel.addChild(new AuthenticationForm());
    }

Now we have a look at the implementation of the form. First the elements to present the form and the element that defines the remote http GET. In the code you’ll find the username TextInput, the password TextInput a Text element for showing a message in case of an authentication error and as said the element HttpService that defines the remote call. Take a good look at the HttpService element. We specify the special spring security url that we post the form to : j_spring_security_check. We define the method to call if everything goes well (result) as well as in case of an error (fault).

    <mx:HTTPService
            id="loginService"
            url="j_spring_security_check"
            showBusyCursor="true"
            method="POST"
            result="loginServiceResultHandler(event)"
            fault="loginServiceFaultHandler(event)">
        <mx:request>
            <j_username>{userName.text}</j_username>
            <j_password>{password.text}</j_password>
        </mx:request>
    </mx:HTTPService>
    <mx:Text id="authenticationMessage" visible="false" styleName="warning"/>
    <mx:Form defaultButton="{submitButton}">
        <mx:FormItem label="Username">
            <mx:TextInput id="userName"/>
        </mx:FormItem>
        <mx:FormItem label="Password">
            <mx:TextInput id="password" displayAsPassword="true"/>
        </mx:FormItem>
        <mx:FormItem>
            <mx:Button id="submitButton" label="submit" click="submitBook()"/>
        </mx:FormItem>
    </mx:Form>

In the code we saw three functions that are called when we push the login button, when a result comes back from the remote service and when an error comes back using the remote service. The function submitLogin just uses the remote service. The most interesting function is the loginServiceResultHandler. Here we call the initComponent function of the Application object. Remember we talked about this when discussing the Home.mxml. The result of this action is that we now have been authenticated on the server and we have security related information stored on the session.

        private function submitLogin():void {
            submitButton.enabled = false;
            loginService.send();
            submitButton.enabled = true;
        }
        private function loginServiceResultHandler(event:ResultEvent):void {
            Application.application.initComponent();
        }
        private function loginServiceFaultHandler(event:FaultEvent):void {
            authenticationMessage.text = "Problem while authentication ...";
            authenticationMessage.visible = true;
        }

We go back to the Home.mxml component. We now call the remote service booksSecurityServices and call the method obtainGrantedRoles which is actually a call to the spring bean. This bean uses some specific spring security classes to obtain the current authenticated user and requests the granted roles from this user. The object that is returned AuthorizationData has the same fields as the flex object AuthorizationControl. Using BlazeDS we obtain the data we want. If you want to know more about the configuration of blazeDS than check my previous post. Most important file is the remoting-config.xml.

public class BooksSecurityServicesImpl implements BooksSecurityServices {
    public AuthorizationData obtainGrantedRoles() {
        GrantedAuthority[] authorities =
                SecurityContextHolder.getContext().getAuthentication().getAuthorities();
        int numAuthorities = authorities.length;
        String[] grantedRoles = new String[numAuthorities];
        for (int counter = 0; counter < numAuthorities ; counter++) {
            grantedRoles[counter] = authorities[counter].getAuthority();
        }
        String username = SecurityContextHolder.getContext().getAuthentication().getName();
        return new AuthorizationData(grantedRoles,username);
    }
}

What do we do when we have received the AuthorizationControl instance? We assign it to our globally available authorization parameter. Then if the user is authorized we initialize the navigation object and clean out the main content panel. The next block of code shows the mxml component representing the remote object as well as the function that handles a successful call. The function isAuthorized is used to check if the authorization we have is not of type anonymous. This role is assigned to any user asking a resource going through the spring security filters

    <mx:RemoteObject id="securityService" destination="booksSecurityServices"
                     fault="authorizationFaultHandler(event)">
        <mx:method name="obtainGrantedRoles" result="handleReceivedGrantedRoles(event.result)"/>
    </mx:RemoteObject>

private function handleReceivedGrantedRoles(eventResult:Object):void {
    this.authorization = AuthorizationControl(eventResult);
    if (isAuthorized()) {
        var mainNavigation:MainNavigationComponent = new MainNavigationComponent();
        menuDock.addChild(mainNavigation);
        mainNavigation.visible = true;
        mainNavigation.addEventListener(components.MainNavigationEvent.SELECT_ITEM, eventAction);
        myMainContentPanel.removeAllChildren();
    }
}
public function isAuthorized():Boolean {
    return authorization != null && authorization.username != 'roleAnonymous';
}

Depending on the user that is logged on, we now have one or two buttons at the top of the screen. Users with the ROLE_ADMIN will see two buttons. One line of code I want to put under your attention is the one with an addEventListener. We will need this line when we start talking about he navigation menu component. Most important to know here is that we add a listener for our own event, just like we would for a click event to a button for instance. Let’s have a look at the important components.

Use user’s roles to hide some ui components

For the navigation we make use of a custom event when a button is clicked. This is used to determine the component to show in the main content panel when one of the buttons is clicked. If you look at the function initMyComponent you can see how we can determine whether we need to show the button for a new book. We make use of the globally available object Application.application which contains our object authorization. The function userIsAdmin just checks if the user has the role ADMIN. In the function clickEventHandler we create a new MainNavigationEvent which is catched by our Home.mxml component like I described.

    public class MainNavigationComponent extends HBox {
        public function MainNavigationComponent() {
            super();
            initMyComponent();
        }
        function initMyComponent():void {
            addChild(createNewButton('allbooks', 'All Books'));
            if (Application.application.isAuthorized() && Application.application.authorization.userIsAdmin()) {
                addChild(createNewButton('newbook', 'New Book'));
            }
        }
        private function clickEventHandler(event:Event):void {
            dispatchEvent(new MainNavigationEvent(MainNavigationEvent.SELECT_ITEM, event.currentTarget.id));
        }
        private function createNewButton(id:String, label:String):Button {
            var aButton:Button = new Button();
            aButton.id = id;
            aButton.label = label;
            aButton.addEventListener(MouseEvent.CLICK,clickEventHandler);
            return aButton;
        }
    }

For completeness I’ll also show the event stuff here. The next function is from the Home.mxml. It is called when the special event is catched. The event contains a method to create a new component that is displayed in the main content panel.

    private function eventAction(event:components.MainNavigationEvent):void {
        myMainContentPanel.removeAllChildren();
        myMainContentPanel.addChild(event.createRightUIComponent());
    }

The next block of code show our custom flex event component. The buttons pass the item that was clicked to the event and based on this value we created the appropriate component like FilteredBooks or BookForm.

    public class MainNavigationEvent extends Event {
        public static var SELECT_ITEM:String = 'selectitem';
        public var clickedItem:String;
        public function createRightUIComponent():UIComponent {
            var createdComponent:UIComponent;
            switch (clickedItem) {
                case 'allbooks' :
                    createdComponent = new FilteredBooks();
                    break;
                case 'newbook' :
                    createdComponent = new BookForm();
                    break;
                default:
                    var label:Label = new Label();
                    label.text = clickedItem;
                    createdComponent = label;
            }
            return createdComponent;
        }
        public function MainNavigationEvent(eventType:String,clickedItem:String) {
            super(eventType, false, false);
            this.clickedItem = clickedItem;
        }
    }

We are almost there. Now you cannot click on the new book button anymore. But it is possible we forget to secure something on the front-end. For the example I have forgotten to secure the update book screen. Now anybody can click on a book and go to the update screen. We need more security, therefore we implement method level security on the server side.

Configure the method level authorization in spring security

Implementing method level security using spring security is very easy, especially when you have done the steps we have done so far. We use aspectJ style pointcuts to select the object and methods that need a certain security role. In our case we select all objects with a name ending with Manager in the specified package. The methods starting with store need the role ROLE_ADMIN. The methods starting with obtain need to role ROLE_USER. To show that it works we open the list of books with the normal user, click on a book, make a change and get the message as shown in the following image. To my opinion this message is not nice, you should prevent the user from being able to do this as all. So do not present the update form but present the data in non updatable form instead.

    <security:global-method-security>
        <security:protect-pointcut
            expression="execution(* nl.gridshore.samples.books.business.*Manager.store*(..))"
            access="ROLE_ADMIN"/>
        <security:protect-pointcut
            expression="execution(* nl.gridshore.samples.books.business.*Manager.obtain*(..))"
            access="ROLE_USER"/>
    </security:global-method-security>

Future enhancements

I am having mostly problems with the session handling. You need to think hard about what to do when the flex app outlives the server session. I also had some problems with new sessions that got started when I did not expect it. This had to do with a remote call before trying to authenticate. What I would like to do is something like a re-authentication when the sessions has died automatically. You also need to think about the length of the session. What should happen if you remove a role from a certain user.

Conclusions

It turned out to become a long article. I hope you had the patience to read it all. I do not think it is very hard to integrate spring-security with flex. All the things I have done for normal web application I could do as well for the flex application. The spring security version 2 is a good enhancement, much easier configuration, but still the possibility to make it pretty complex. Convention over configuration is well used. As for flex, just a few remote calls like in our previous posts.

I hope you like the article, drop a comment if you have questions or if you have found this useful.

References

• http://www.mail-archive.com/flexcoders@yahoogroups.com/msg35921.html
• http://static.springframework.org/spring-security/site/reference/html/namespace-config.html
• Code sample (check the books-overview)