I'm currently looking for a security project to add to a base architecture for my upcoming projects and found about jGuard searching in the wikipedia.
I'm new to it, just a pair of days reading docs and code (v1.0.3), but i will be glad to have some insight from you on some spots.
1- Why does jGuard need to administer my users and roles? I understand that i can provide custom loginmodule/authmanager, but even that, the philosophy seems to remain deeply rooted to jGuard. In a user-service oriented webapp, user management and caching has so many desing involvements that integrating jGuard will break the application. More on that, Hibernate benefits and optimization opportunities are greatly diminished when half of the data has something to do with users and roles. What do you think about this? The first solution that comes to my mind is to use minimal users and roles in jGuard and use the stored ids to map users in the code.
2- v1.1.0 is still in beta, do you have some roadmap or schedules for us to see?
thanks for your comments.
about your questions:
1- when you use jGuard, you use JAAS and jGuard on top of it.
so, you can provide some custom loginModules, and don't use AuthenticationManager/AuthorizationManager implementations provided.
i'm agree that if use jGuard out of the box, the philosophy of user and role management will be driven by it.
your management will rely on an advanced Role Based Access Control model(RBAC) called ABAC (attribute based access control).
about design involvement, and issues which break applications, can you explain a little bit more, if you can with one example?
about Hibernate benefits and optimization lowered with user an droles data, can you give some details?
Hibernate use will permits to support many databases,and internally will permits to avoid SQL queries and only stay on the object oriented paradigm.
2- about v1.1.0, the beta3 (last beta before final release) is very closed to be done. some test cases fails, andwe work to fix all of them.
it adds multiple organizations support for some complex needs.
the remaining gap for the final one is to reestablish other authentication mechanism like BASIC and CLIENT-CERT ones.
can you give me your feedback about my comments?
can you also explain your needs about jGuard which are not fullfilled?
Let me start a test project and try jguard, so i can tell from experience. My main concern is about who controls user data (mainly, user CRUD operations). Im rather busy at work this month, so i'll come back in some weeks with the homework done...
you will have the ability to test the shortcoming 1.1 beta 3 release when you won't be busy.
I also do think that jGuards value can be increased by a better way to integrate an (mostly already) existing user management. The value of RBAC is the separation of the user management from the rights management. With jGuard this is strongly coupled again (to my opinion). The modeling of the organisation (including the user's role) as well as the user as such should get decoupled and made accessible through an adapter. I see the JguardUserPrincipal mechanism (with the user template) as such a strongly coupled mechanism. The db schemas for all the necessary (or unnecessary) fields should get better decoupled in a more abstract mechanism in which one (only) needs to tell jguard in which (mostly already existing tables) the minimun information (user, password, role, user identity features, etc) can be found (like in the JPA mechanism way (for me there is a difference between a JPA orm.xml external configuration way and the used Hibernate way).
Maybe you had that in mind when you started the HibernateAuthenticationManager (jguard 1.1)?
BTW: What I like very much about jGuard is the ready-made authorization mechanism. That is what is missing in the JEE world which uses JAAS.
Those are some thoughts of mine.
thanks for your feedback!
we've used the HibernateAuthenticationMAnager for the ease of development and flexibility, and for other advantages of using an ORM tool.
one step forward would be to use a JPAAuthenticationManager and a JPAAUthorizationManager (help is welcome).
but on this side, turing the jdbcAUthorizationManager into an ORM-like implementation is a challenge too.
RBAC implies users, roles and permissions.
jguard decouples authentication (user and roles), from authorization (roles and permission).
so, there is only a light coupling effect between these two domains, with a role mapping (roles defined in authentication by a role name and an application name, should map the role name in authorization with the application name.
so, jguard tries to provides out-of-the-box datastore (xml/database/ LDAP in the future).
but i acknowledge that some legacy systems already built, need to not refactor them to use jguard: some adapters need to be provided.
the 1.1 release will be out when the rearchitecture of jguard will be done (almost finished), and some previous features lost in rearchitecture will be shipped again (some authentication mechanisms).
the 1.2 release, will contain, as my opinion, the HibernateAuthorizaitonManager (or its JPA counterpart), and a simplification on authorizaiton (removal of domain which only add complexity).
help is wanted to add other additional features, like adapters in forthcoming releases.
thanks for your feedback!
if you're agree, we will be pleased to hear some critics about some parts of code too, or about other features.
it came into my mind to discuss my problem with JGuard here for architectural (system architecture as well as JGuard architecure) reasons.
I like to invite all interested individuals. My idea is closely related with the above answer of Charles responding to my "ranting".
In my above posting I said that I wished to have a better decoupling of user management (creation of identities/users and roles) from the roles and their permissions as conceptualized in RBAC.
Above, I wished that the out-of-the-box datastores (db, LDAP, etc.) support more flexibility in respect to existing systems.
My wish goes like following:
Usually, nearly every webbased application contains an access control part. It has its own user management as well as its own authentication and authorization. If you want to couple two or more applications together under a singleSignOn management (SSO) then you need to have a better (i.e. a somehow centralized) control of the user management (UM) and authentication mechanismen (authn M) as well as a distributed authorization (authr M) (coarsly expressed).
As in my case of a certain association: We do have two groups of users (association members and non-members). The members are able to access parts of "our portal" which non-members are not allowed to access. The members themselves do also have different rights, lets assume to have ordinary members and some kind of moderators who are able for the management of certain association informations the members can read. The non-members may use the newsgroups/forum the association offers. Of course, the association members do have access to the forum inclusive, i.e. if one is member association it may also access the forum)
As common, the forum comes with the whole set of identity access control management (IAM) mechanisms as mentioned above (UM, authn M, authr M).
We do have the requirement that the member access should have a SSO mechanism, so that an association member can use the member area as well as the forum with one single login.
Consequently, there are existing db tables realizing the IAM of the forum. For the member access there is very probably another set of UM, authn M, authr M mechanisms, simply the forum db tables do not contain the necessary information for members.
Now there is my invitation for discussion: How to realize this with jGuard?
The authentication management of JGuard relies on an own model of how the user management needs to look like (on the level of db tables), especially in respect to the necessary Java authn/authr mechanisms (I mean Principal, public/private Credential, Subject, etc.). For my part, I am overly forced to follow the JGuard model of user/rights management which is realized by the JGuard JAAS LoginModule. Check this image to see what I mean: http://jguard.sourceforge.net/mvnsite/docbook/jguardERDiagram.jpg (check out the whole thing on xml base: chapter 22.214.171.124.2.4. jGuardUsersPrincipals.xml example in http://jguard.sourceforge.net/mvnsite/docbook/en_jGuard_reference.html#d108e674\)
Sure I could create my own LoginModule. But I feel this is reinventing the wheel and is not much help and in fact it is not the Implementation of the necessary methods of the JAAS framework itself which are difficult (see: http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#Intro\) but - and this is my claim which I wish to get discussed - the realization of the IAM concepts (this is for example the JGuard <userTemplate>-mechanism as well as the idea of the ABAC-concept) and the realization of the decoupling of (user->roles) from (roles->permissions) on the persistence level
To come back on the architectural path.
- Integration of existing mechanisms how could this be realized? And in my case: how could the existing db tables of the forum be integrated - one want to reuse the password the user set before he became association member.
The more I consider the problem the more I believe has to neglect the existing tables completely, implementing the SSO completely on its own and only mirroring the existing data of the forum. In consequence, there is much (this is unnecessary code) to program in case of application integration where one wished support by a framework. What are you thinking? Do you share my view? Do you have a better approach (than reprogamming) to this problem?
I would wish an interesting discussion arises.
So long, chk
tahnk you very much for your comments.
sorry for the delay to answer, and the shortness of it:
i'm agree with you about the need to have a lighter dependency with legacy system, or sso ones.
a better documentation and a lighter work need to be required to integrate these use cases.
so, more decoupling is needed to integrate systems which provideds an identity but without roles, or boths, or two subsystems which provide each ones identity or roles.
the team is listening very carefully user feedback.
we are focus mainly on the next 1.1 release (and enhancing documentation), to have a robust code ground.
it will permit to build on it more easily features from feedback.
starting with this 1.1 release, we will focusing on delivering releases with an extreme reduced delay for a better quality, to satisfy in a better way jguard users.