How are you doing authentication in your Flex app?

Question

Do you build all your login, account creation, password recovery, etc. into your Flex app, or do you keep all of that in web pages and only redirect to the .swf on successful login?

Answer 1

I am close to finished on a medium sized flex app that has a Drupal back end. I've used RemotObjects talking via AMFPHP to drupal for all the login and verification routines. The only thing I redirect to HTML for is actual new user registration. However knowing beforehand that Drupal, Flex, and AMFPHP played very well together definitely made the decision easier!

Answer 2

We do it all in Flex in a pretty complex app, there's no reason to divert to HTML. Since Flex talks (stateless) HTTP to the backend if you use AMF, you need session support in Flex anyway.

Answer 3

It's pretty easy to communicate with a server over http (a normal webserver) in flash. If you don't do heavy data-exchange with a server, AMF might be overkill and JSON, XML or your own format will suffice more than enough.

http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/URLLoader.html

http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/URLRequest.html

EDIT: I mean't to say flash, not flex.

Answer 4

We do our login page in HTML/JavaScript and use AJAX service calls. We never touch our Flex .swf code until a user gets successfully authenticated. This page is also where we verify presence of Flash player and if is of a sufficient version to run our Flex code.

On the server-side we're using Tomcat, BlazeDS, and Spring-Framework. We have Spring controllers that divert any attempted unauthenticated access - BlazeDS remoting calls, etc. - to the login page. We're using Spring security to manage authentication and user role permissions (this used to be referred to as Acegi security, but it has merged to be under the Spring umbrella).

We used to try do a login page in Flex but gave up due to some weird focus bugs. We couldn't get the focus to always reliably be in the login credentials edit field. The forums revealed there was a know focus problem with the first-time access of a Flex form.

For the user login experience we absolutely wanted to make sure the focus was well behaved. First impressions are the lasting impressions.

Answer 5

The way we do it, is

1) Flex front end talking via remote object to a Java Facade on a webserver.

Java:

public class AdminServer {
  //injected into contr..
  private final LdapService ldapService;

  public UserDisplay authenticate(String username, String password) {
    return ldapService.authenticate(username,password);
  }
}

2) Ldap authentication and exception handling

The java then makes a call to an ldap server via a delegate method (left out), the UserDisplay object is populated, and always returned, with an state to represent success/failure/exception, and the Authentication level of the user. You can do this your preferred way.

3) We then expose the AdminServer as a flex destination in the spring/config as:

It is important that destination="adminServer" (below) matches the bean id in the spring config (above).

4) In the flex code: ..

5) Use the AMFSecureChannel To prevent the password being sent in the clear from flex->java, you also need to use the AMFSecure channel in your flex config file, by setting it as the default.

6) Use Ldap certificate and keystore to secure comms java->ldap

The java stuff should have the ldap certificate to use for its encryption, which in our case meant configuring a keystore (see java keytool) file on the server (Tomcat) with the following imported in ORDER:

1. The top level certificate of root trust
2. the certificate that signed our key pair
3. Our generated key pair, which we sent for signing by (2).

If you do not observe this order, you will not import your public/private key

7) Location of keystore file

This file was put in ~/.keystore to automatically get picked up by tomcat.Your server may be different.

8) use the webserver secure port Finally, we had to uncomment the tomcat https in the server.xml config to allow the secure channel to work on port 8443.

Then we could type: https://www.oursite.com:8443/ourcontext/login.html

and get secure communication all the way.