Great ;)

keep us updated!

regards,

Martin

On 10/9/05, Duncan Mills <[EMAIL PROTECTED]> wrote:
>  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
>
>
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Reply via email to