Dominik,
> 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:
So if I understand you right - you are hiding various page elements,
and protecting method access... but not hiding entire pages? Meaning,
there is no situation in your app where they request a certain resource
and you simply redirect them to a login screen?
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.
