Just like Red Two in Star Wars Episode 3 I'll try to "Stay on Target" "Stay on Target" and not hijack this thread. Like Hank I'm sometimes feeling the 'newb' factor.
One of the next web services I'm looking to integrate uses a username / password to create token via WSSAddUsernameToken. Its package is org.apache.ws.security.message. Or so the co-worker who has built connectivity to that out through J2EE tells me. Each client system connects with it's own user / pass combo. So I believe I should be able to write these into the named proxy web service connection (having issue with that also, put a separate post out for it) on FDS to be secure. Is this the 'J2EE auth' of which you speak? From my googles it seems a fairly standard approach, still lost on the FDS side as to how to integrate such things. Thx, Jamie --- In flexcoders@yahoogroups.com, "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 >