Best authentication mechanism for Flex, ASP.NET and SOAP or REST web services?

Question

I am building a web based application written in ASP.NET and Flex. One of my biggest challenges is implementing security for the application in a flexible and maintainable way. This challenge is compounded when different technologies are involved. I'll try to describe what I have below.

The website is laid out as follows:

• /mydomain.com/
  • Login.aspx
  • Default.aspx (hosts flex [.swf] application)
  • /Administration/
    • AddUsers.aspx
    • AddRoles.aspx
    • AddPermissions.aspx
    • etc...
  • /Services/
    
    • SecurityService.asmx
    • MapService.asmx
    • PhotoService.asmx
    • etc...

I am currently using forms authentication to secure the resources on the website. All pages/resources not in the /Services/ folder require an authenticated user and will be redirected to Login.aspx if they are not yet authenticated. The .asmx pages allow unauthenticated users. To secure these resources I throw an exception in the SOAP method. This avoids redirecting pages for SOAP web services which is not supported by any SOAP web service clients I am aware of. Finally, SecurityService.asmx contains a Login method to allow the Flex application to Login without redirecting to the Login.aspx page should the cookie expire for any reason. Because the cookie established is sent with any request to the server, including requests coming from the Flex application, this seems to work pretty well.

However, this still feels like a bad approach securing web services. I feel like I am using Forms Authentication for something it was not intended for. Specifically, I am concerned about:

• This model will not work when the services are separated from the core website. This is a newly discovered requirement and I believe that Forms Authentication is not going to work well (if at all) without a lot more modification and trickery.
• Clients other the Flex may require access to the services. Some of these clients may not even be able use cookies. If so, this model immediately falls apart. This is not an immediate requirement but it is known that this is one of the long term goals.
• We will eventually (hopefully sooner rather than later) move to a REST based architecture (vs. SOAP) so any solution needs to work for SOAP and REST.

So, my question is.

What are the best authentication and authorization mechanisms for securing an application built on ASP.NET, Flex, and SOAP or REST web services?

Note: I am actively looking into OAuth; however, I am having a difficult time finding complete examples from which to learn. Additionally, I need to be able to filter the data returned for a given user based on the permissions that user has, OAuth seems to remove the identity of the user from the token. As such, I am not sure how OAuth applies in a fine grained security model.

Answer 1

Others may disagree, but I actually don't see a huge problem with handling it the way you are now; that's probably how I'd handle myself, at least initially. One way or another, even down the road, you'll probably want to keep the Flex app aware of the authentication state of the session, so if that means checking the ASP.NET session token directly, or some other cookie you set when you set that one, it seems like a fine and reliable way to go.

I do see what you mean about the services redirecting, but even so, with forms auth, it's not so much the service specifically that's handling the redirecting so much as the ASP.NET app itself. Later, should you need to use a different authentication scheme, you can consider that scheme's specific implementation considerations. Unless you've got concerns about using forms auth in general, there's probably no need complicate your approach simply because of the Flex client and Web services.

Answer 2

I admit I don't work with web services much, but what about requiring an access key as a soap header parameter? Any client app which can communicate with a soap web service is likely to have a low level API to modify the soap request, and use of the access key allows you to (in theory) limit the use of the service. Google, Amazon, and several other providers use this type of authentication for their web services and it seems to work very well.

This article seems like it might be a good place to start...

Answer 3

I think it's best to have independent authentication systems - even if there are relations between the user and the auth tokens on the back end. They are different beasts that have differing capabilities and demands.

Use the normal forms based auth for the flex portion. That is good.

For web services, you could create a login method that returns some auth token which is used by subsequent tasks to execute. Or add a few fields to your web services (posted in the header or as params) to use a userid/password combo for authentication each and every time.

A side note: I wouldn't rely on a soap exception to handle authentication problems. But you wouldn't need to worry about the redirection if you send an auth token or user/pass with the WS requests.

EDIT: RE: Comment- Ideally there is. There are products out there (Tivoli access manager) that service those needs, but they are expensive.

I gave this recommendation because it eases the pain of allowing access to alternative clients and as long as you designed the services correctly it's stateless. It also gives you finer grained control over data level access on the service side of things.

Answer 4

The WCF Security Guide published on CodePlex may help you there, if you are using, or can use WCF.

There's also Microsoft's Web Services Enhancements (WSE) 3.0 which I believe implements some of the WS-* security specifications.

Hope that helps.

Answer 5

If you move your services to another place, then the standard ASP.net authentication cookie can be re-used if both web apps have the same machineKey in the web.config.

As far as I know, FLEX will honour the asp.net authentication cookies because it will make http requests through the browser, which will pass the http cookies (including the asp.net authentication ticket) like a normal http request.

Have you tried securing your website and services using normal asp.net authentication yet?

Answer 6

See Web Services authentication - best practices?

Dave Dunkin wrote:

The easiest way to handle it across a variety of platforms is to use HTTP basic authentication and HTTPS for the transport layer. WS-Security would be good if your needs go beyond simple username/password but the support is going to vary quite a bit between platforms. HTTP authentication is supported by every decent SOAP implementation.

and my Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.