Hi Hank, No reason to feel insecure about any of this :)
The specifics of authentication configuration are generally going to vary a bit depending on the servlet container you're using. I think one reason why the FDS docs for this are on the light side is because configuring a servlet container to auth against a database schema or LDAP directory or ... is something that your servlet container's docs should explain and aren't standardized. Here's a link to configuring security realms for Tomcat for instance: http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html Once you've configured your servlet container to use your database of users and roles, protecting your FDS destinations is pretty simple. You just need to specify the roles that are allowed to access any protected destinations. Once you've added security constraints to the destinations that require them, in your Flex app you'll want to write a simple form to get a username and password from a user and then use the setCredential() API on whatever client component you're using to interact with the target destination. So if you add a security constraint to a remoting destination, you'd do something like this to make your call: var ro:RemoteObject = new RemotObject(); // set the proper destination, etc. // then set credentials on the instance; you'd get username // and password via a form exposed to the user. ro.setCredentials(username, password); // then make your call ro.invokeSomeMethod(); Before the method is invoked, your credentials will be sent to the server to authenticate the user. The setCredentials() method is defined for RemoteObject, HTTPService, WebService, DataService, etc. The login command class you specify in services-config.xml is used to log the user in on the server. You don't need to do anything other than specifying the proper login command for the container you're running in (e.g. don't use the JRun login command if you're running on Tomcat). The various implementations do whatever is necessary for that given container to authenticate the supplied credentials and if they're ok an auth'ed Principal is stored in the client's session. This Principal is used to test that a client can access protected destinations based on role constraints. The only reason you'd need to worry about the login command API directly is if you were trying to run FDS on a container we don't support directly, or you have a very custom authentication scheme that you need to use because your container's native authentication isn't satisfactory (not likely). HTH, Seth ________________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of hank williams Sent: Wednesday, November 29, 2006 8:03 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] role based security vs session based security with a servlet container By the way, after feeling quite insecure that I should really understand all of this, but not, I did a little googling and discovered that either this is so simple that it requires no documentation or discussion, or no one is doing security properly with FDS or no one is using FDS with authentication. the search "flex.messaging.security" turned up 51 hits on google which turned into maybe half that number of real hits. None of the hits was particularly helpful, but the first hit is actually a javadoc description of LoginCommand. Its *one* line. the same search turned up only 8 threads in flexcoders. In each of the cases where it is referenced it is just people including their service-config.xml files. No explanations of anything. In the online documentation flex.messaging.security turned up exactly one hit which really just explains that there *is* a loginCommand API, but not explaining how any of it works or is used. By the way, my search results for setCredentials are similarly sparse. So are flexcoders just not using FDS or are they not using Authentication, or is everyone who is doing this just so much more knowledgeable than me so no discussion anywhere on the net or on this mailing list is required? Hank On 11/29/06, Seth Hodgson <[EMAIL PROTECTED]> wrote: > Hi Hank, > > How do you do your logins now against your account database? You're not using > general J2EE auth? > > Role based security in FDS just wraps the existing J2EE auth machinery > provided by your app server. You can code your login UI in your Flex app and > before any calls or data exchange are permitted through a protected > destination authentication will be performed automatically using the > credentials you've specified via setCredentials(). You add a security > constraint to a destination like so (only users who are members of the > 'admin' role are allowed access in this case): > > <destination id="..."> > <security> > <security-constraint ref="admins" /> > </security> > ... > </destination> > > The actual authentication is performed via an app server specific login > command class. FDS ships with implementations for all supported servers. The > command class to use is specified in the security section of the core config > file like so: > > <security> > <login-command class="flex.messaging.security.JRunLoginCommand" > server="JRun"/> > ... > > I'd recommend using J2EE auth as opposed to trying to role some other custom > approach. When security is involved it's really best to use existing > libraries and frameworks that have been heavily tested (J2EE auth for > instance), because bugs in this area tend to be more dangerous than bugs in > your UI code. > > HTH, > Seth > > ________________________________________ > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of hank > williams > Sent: Tuesday, November 28, 2006 10:01 AM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] role based security vs session based security with a > servlet container > > I am trying to figure out the best way of implementing security & > authentication. I am using tomcat, and FDS at the moment for remoting. My > server side code is obviously in java. > > A while back, role base security was recommended as the way to implement > security. The idea being that if someone did not have the right credentials > that they would be prevented from gaining access to the flex app. But my > problem with this is that I want to do my authentication UI *in* flex, so I > can't prevent people from getting to it before I have had a chance to > authenticate. Another problem with the role based stuff is that, as I > understand it, roles are maintained by the container. I am not clear how to > use my account database (JDBC/Mysql) in this process. > > What seems easier to me is using sessions, because I can, from any server > side function, request the current session of the given user. I can look to > see if their session is valid, how long they have been logged on, etc. And > using this methodology, I can do login in the flex application, which just > sends a login message to the server, the server adds a record to my session > record that indicates that I am logged in and when I logged in. > > This second approach seems like the best approach and the one that gives me > the most flexibility. But I am looking for validation regarding my approach > here. Am I doing something wrong here? Are there some reasons that the role > based security would be better? > > Any insight from people better versed in security than I am would be greatly > appreciated. > > Hank > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > Yahoo! Groups Links > > > >
