> Sounds like file downloads must be an integral part of your application. > What approach did you take for this?
Yes, it is ;). I've done something like this: --> There is a base project, containing all classes responsible for file downloads (There are different types of downloads, downloads get logged in the database, etc.... it's important to know, that there is no reference to any j2ee specific class expect the HttpServletRequest and HttpServletResponse class) --> There are other projects (WebApplication specific projects) which are depending on the previously described project. They are using the download classes in different ways. (One is calling the download classes in a ServletFilter (That's the case in my JSF application), another web application is using the download classes in a Servlet (That's used for the eclipse update mechanism)). If there are any questions, just let me know. Dominik -----Ursprüngliche Nachricht----- Von: Jeff Bischoff [mailto:[EMAIL PROTECTED] Gesendet: Montag, 6. November 2006 20:32 An: MyFaces Discussion Betreff: Re: AW: [O/T] JSF Best Practices for Authentication/Authorization > The first part: Authentication itself > ------------------------------------- > The authentication is using a tomcat realm, which I've implemented on my own > (Because it has to be a hybrid realm (Database and LDAP)). The realm is > returning one of the four roles mentioned above. User's having no role, are > not allowed to access any page. Thankfully, I have simpler requirement of only using a DB for login info. When you use tomcat authentication, do you use your own custom-designed form or that built-in prompt? > --> To prevent properties of my bean to be accessed by someone who is not > allowed to do so, I am using self defined annotations... this looks > something like this: > > @SecurityGuard(TypRoles.ADMIN) > public AdminBean getAdminBean() > { > JsfSecurityManager.getCurrentInstance().check(); > } Very interesting. Alas, we are still on Java 1.4 and thus I can't try out the annotations. Fortunately, I'm more concerned about implementing page-level authorization right now. > The JsfSecurityManager is used in ServletFilters (or in servlets) too, for > example I've a ServletFilter for file downloads, which calls the > JsfSecurityManager too. > Sounds like file downloads must be an integral part of your application. What approach did you take for this? Thanks for the very detailed response Dominik. I may have to re-read this a third time, since there is a lot to digest! ;) Regards, Jeff Bischoff Kenneth L Kurz & Associates, Inc Bieringer Dominik wrote: > Hi Jeff, > > I want to share the way I am handling security in my application. (I am > pretty new to JSF, just started my project some month ago and there is so > much left for me to be learned in JSF ;D). > > There are some requirements in my application: > --> There are 4 supported roles (customers, internal, development, admin) > --> Users/passwords roles are stored in LDAP and DB. > --> You can think of my application as a platform for stored files, each > file having individual access rights. So there are not only pages which have > to be protected, but also different content has to be shown on some pages > depending on the logged in user. > > I tried to separate two things in my application: > --> The authentication itself (which is done by the container, in my case > tomcat) > --> Protection of pages, files, etc... (which is done by my application) > > > The first part: Authentication itself > ------------------------------------- > The authentication is using a tomcat realm, which I've implemented on my own > (Because it has to be a hybrid realm (Database and LDAP)). The realm is > returning one of the four roles mentioned above. User's having no role, are > not allowed to access any page. > > Protection of resources in my application > ----------------------------------------- > For being able to protect pages from being accessed by unallowed users, I am > using two mechanisms: > --> First of all, to prevent some elements on the page from being rendered > and therefore accessible, I am using JSF Security framework > (http://jsf-security.sourceforge.net/). > --> To prevent properties of my bean to be accessed by someone who is not > allowed to do so, I am using self defined annotations... this looks > something like this: > > @SecurityGuard(TypRoles.ADMIN) > public AdminBean getAdminBean() > { > JsfSecurityManager.getCurrentInstance().check(); > } > > I am using my security guards not only in JSF, but also in an AXIS web > application which provides web services and also in another web app, which > provides the files stored on my server for the update mechanism used by > eclipse. > > So there are several implementations of the SecurityManager, which provides > abstract access to the container managed properties like logged in user, and > the associated roles. > > That way it's not possible to access any methods or properties even if the > security provided by JSF security framework is broken. > > The JsfSecurityManager, which is a subclass of SecurityManager (A self > defined class too), provides access to some other useful classes for > permission checks, like a class called PermissionCheckerPackage, which get's > initialized by the SecurityManager with crucial information, like the logged > in user and his roles. With the PermissionCheckerPackage I am able to check > whether the logged in user is allowed to access files or not. > > The JsfSecurityManager is used in ServletFilters (or in servlets) too, for > example I've a ServletFilter for file downloads, which calls the > JsfSecurityManager too. > > > > Mhm.. that's what I've done for providing security in my application. I > would like to hear what you think about that... Maybe you have some good > comments which show me some possibilities for my future projects. > > Thx, > Dominik > > -----Ursprüngliche Nachricht----- > Von: Jeff Bischoff [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 3. November 2006 22:20 > An: MyFaces Discussion > Betreff: Re: [O/T] JSF Best Practices for Authentication/Authorization > > As for my specific requirements: > > I have a simple intranet application. There is a public (no auth) > section, and a secure section for logged-in users. My main requirement > is simple. I want to force the users to authenticate (log in) before > they access the restricted portion of the application. View paths to > this portion are predictable (i.e. /public/* vs /system/*). Desired > authorization scheme will be rather simple (e.g. admins, users, > unauthenticated). I may want control-level access controls later, but I > feel that a good approach to page-level authorization is the most > important goal here. > > It almost sounds like container-managed security would be sufficient for > my needs. However, the documentation from my container (JBoss) seems > overly detailed and complex - I couldn't even tell when they were > talking about JAAS rather than container-managed security. Is this > overkill for me, or am I seeing more complexity than there has to be? > I'm just not sure yet... > > Thanks guys for your time, thoughts, and opinions... > > Regards, > > Jeff Bischoff > Kenneth L Kurz & Associates, Inc. > > Jeff Bischoff wrote: >> Greetings Colleagues, >> >> I have often wondered what the majority of you are using for >> authentication and authorization in your non-public websites. Over the >> last year on this mailing list, I have seen bits and scraps of >> discussion on this topic. Most often, I hear mention of solutions like >> container-managed security and phase listeners. Sometimes custom >> navigation-handlers or servlet filters get mentioned too. Cant' say I've >> quite seen evidence of any consensus on which of these is preferred, so >> I'm interested to hear your thoughts. >> >> I have come across this article [1] which offers an approach (and some >> source code) to authorization in JSF. What are your opinions on this >> approach? Would you consider this and similar approaches to be best >> practice? What other alternatives can you recommend (from experience)? >> >> I will post my specific requirements for my security search as a reply >> to this post, so as not to narrow the overall discussion. >> >> [1] http://java.sys-con.com/read/250254_1.htm >> >> Regards, >> >> Jeff Bischoff >> Kenneth L Kurz & Associates, Inc. >> >> >> >> >> > > > > >
