Re: Login system security

[Duncan Mills]

Yes protecting views by role in the same way that Struts can assign roles to an Action is next on the list - I just have to think about the best way to do this and co-exist with any custom viewhandler impls and a reasonable format for the additional metadata required. Duncan Martin Marinschek wrote: This is a very interesting project - will need to check it out for my next web-app ;) Will you also restrict delivering a view based on the user role? This is the third layer of security restrictions necessary in JSF... regards, Martin On 10/6/05, Duncan Mills <[EMAIL PROTECTED]> wrote: Right - the nice thing about the jsf-security EL extensions is that they don't have to be driven from Container Security you can plug in pretty much any home grown concept of a login page to authenticate and then your own auth mechanism as well. For instance if you take the approach of using a "userInfo" bean on the session which is generated by your own login process then it's trivial to hook that up into the EL interface I guess the next phase of js-security where we're going to start protecting navigation targets based on role will be of interest to you was well Duncan Dave wrote: This is great! I posted a message before about how to login without any protected page. I looked at authenticator package where there is FormAuthenticator. I like to do similar, but without a protected page. User can click a login link and register all necessary info with session after successful authentication, and stay in the same page. The page will render differently depending on roles. It was suggested to have a dummy protected page that will redirect to current page. The problem is that the current page is stateful using <saveState>, and the data will not be available by redirecting from the dummy protected page. I looked the source code of servlet authenticator package. But have not figured out how to the realm object to call authenticate(....). Any help is appreciated. Thanks. Dave Duncan Mills <[EMAIL PROTECTED]> wrote: Several Points here 1) Using Security Attributes within your pages. I'm about to release 1.0 of the jsf-security project on SourceForge (www.sourceforge.net/projects/jsf-security) this provides extensions to EL which will give you a new scope #{securityScope} and a bunch of attributes and pseudo functions such as #{securityScope.isUserInRole['manager,admin']} which allow you to use expressions to control rendering and read-only states of components - even if they are not "role" enabled in the way that the myfaces components are. jsf-security is fully pluggable and so if you use Acegi or a home grown Authorization / Authentication mechanism you can plug it in underneath the same consistent EL. The current version hooks into Container Security, and we've j ust started a JAAS adapter as well. If anyone wants to get involved - particularly of you use Acegi today get in touch. For more info on this see this blog entry: and the project on SF. You can pull the source from CVS today and build - it all works I just need to write the doc and the localize the message strings... 2) Using the database to Authenticate / Authorize Your mileage will vary from container to container, but with OC4J (& Oracle App server) you can plus in your own custom login modules that can do just this - Frank and I who work on the jsf-security project just posted a paper on that process a few weeks back: Declarative J2EE authentication and authorization with JAAS Duncan Dave wrote: hi Andrew, How to get a Realm object so that I can call authenticate()? I am using Database to store username and password. Thanks. Andrew robinson <[EMAIL PROTECTED]> wrote: I am using the built in Tomcat DataSourceRealm so that single sign-on is possible. My login is still using a normal JSP instead of JSF, so I can't use JSF components to build my login page. Has anyone integrated the form-base web.xml authentication with a JSF login page? On 10/4/05, Mike Kienenberger <[EMAIL PROTECTED] > wrote: I've switch from a login page to a filter that authenticates and sets the User database record in the session. (Actually, I fetch this record every request, and store it in the request, but that may be too excessive for your situation). I then have additional filters that work on that data to provide coarse-grain security (ie, if you don't pass the filter, you can't access any of the application). I also have a SecurityRoleManager bean that provides fine-grain control by operating on the record stored in the session. Ie, "securityRoleManager.canEditDate()" On 10/4/05, Eurig Jones <[EMAIL PROTECTED]> wrote: > I'm trying to decide on a Login/Logout system to protect my files using > JSF.. I've played about with extending NavigationHandler, but the > problem is, it doesn't protect the files which aren't JSF, a nd you can > still run the JSP files if you wanted to... > > How have you people gone about a database driven login/logout system > using Faces? > Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. -- Regards Duncan Mills Senior Principal Product Manager Oracle Application Development Tools [EMAIL PROTECTED] Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. -- Regards Duncan Mills Senior Principal Product Manager Oracle Application Development Tools [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German