Gridshore » authentication

Feeling secure with Web Services – Part 3 – Digital Signature

Allard — Sun, 01 Jun 2008 15:10:55 +0000

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 .

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by each other;
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.

Feeling secure with Web Services – Part 2

Allard — Mon, 26 May 2008 19:23:04 +0000

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.

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by each other;
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:

The client will send a “Hello” to the server.
The server will response with a “Hello”, and send a certificate to the client
The client will decide whether it trusts the server’s certificate
The client will use the servers certificate to encrypt its own certificate and send it back to the server
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”.

Feeling secure with Web Services – Part 1 – The UsernameToken

Allard — Tue, 20 May 2008 19:25:59 +0000

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.

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
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:

username Zb5nkZdaXM3hH/bVPQRdMdYSbdo= hHDHOSh3akTwwZFs+6o13A== 2008-05-20T19:00:06.937Z

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.

[1] Make sure you checkout the code in the /trunk/feeling-secure-with-webservices/ folder. If you check out the entire trunk, you’ll have to deal with lots of samples.

Feeling secure with Web Services – Introduction

Allard — Sat, 17 May 2008 13:45:27 +0000

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:

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
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] Jip and Janneke are two very popular cartoon characters for small children. You might just recognize them: http://images.google.nl/images?q=jip+and+janneke&hl=nl&um=1&ie=UTF-8&sa=X&oi=images&ct=title

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

Integrating flex 3 with spring security (formerly known as Acegi)

jettro — Sun, 11 May 2008 08:49:15 +0000

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.

    
        org.springframework.security
        spring-security-core-tiger
        2.0.0
        
            
                org.springframework
                spring-support

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.

    
        springSecurityFilterChain
        org.springframework.web.filter.DelegatingFilterProxy
    
    
        springSecurityFilterChain
        /*

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.

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.

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).

    
        
            {userName.text}
            {password.text}

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

    
        
    

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.

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.

Gridshore » authentication

Feeling secure with Web Services – Part 3 – Digital Signature

Feeling secure with Web Services – Part 2

Feeling secure with Web Services – Part 1 – The UsernameToken

Feeling secure with Web Services – Introduction

Integrating flex 3 with spring security (formerly known as Acegi)

Introduction

Configuring Spring security (authentication and resource authorization)

Configure flex to use spring’s authentication

Use user’s roles to hide some ui components

Configure the method level authorization in spring security

Future enhancements

Conclusions

References