Thanks Seth. I actually think I get it now! Of course who knows what will happen after I try it bu the ideas all make sense to me.
Regards, Hank On 11/30/06, Seth Hodgson <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > -- > 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 > > > >
