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.

Reply via email to