2007/11/13, glassfish_at_javadesktop.org <glassfish_at_javadesktop.org>:
> Witold,
>
> I am afraid we are not talking about the same rights here. You are talking about JEE users/rights, I am talking about rights and users at application level.
>
> More below...
>
> > 2007/10/18, glassfish_at_javadesktop.org
> > <glassfish_at_javadesktop.org>:
> > > Right... ahem, not so much :) The issues we have
> > with this approach are:
> > > a) security - you can tweak the client and force it
> > to send different ID, impersonating someone. Having
> > that in server in SFSB you can send whatever ID you
> > want it will still use the one you were assigned
> > after login.
> >
> > If you can tweak the client in a way that it will act
> > like someone
> > else in front of JavaEE server - then you will find a
> > serious bug in
> > that particular JavaEE server, but I doubt you could
> > do this, because
> > security is one of the most important thing in JavaEE
> > world and I am
> > sure there are no serious JavaEE implementations that
> > lack in the
> > elementary security areas.
>
> Nope, I am talking about ID that is stored in the application database, assigning him role and access to actions, limited result sets etc.
> > > b) would you give me an example how does EJB
> > automatically filter results based on dynamically
> > applied filters and rules based on user ID? (that is
> > more sarcastic, rhetorical question just in case you
> > were wondering...). I mean lets say we have a list of
> > contacts. User ID 1 can see all, user ID 2 can see
> > only those that have "Support" tag etc. Everything is
> > dynamic, stored in database, unknown at design time.
> > Now, if you show me how EJB will do that
> > automatically, I will be grateful and will be keen to
> > apologize for being sarcastic.
I really do not understand what you mean. You said about security:
"you can tweak the client and force it to send different ID". I will
say again: NO, you cannot tweak client and expect server to be
misinformed about WHO is accessing it. Let me explain more verbose how
security can be used in JEE world.
Lets say you have users in database. You have table with users and
table with user groups, where in user table you hold users' logins,
passwords and whatever you want, in groups table you have associations
between users and their groups. If you want - you can configure
Glassfish to map 1:1 user groups to roles - which would mean that
"users" group will automatically be mapped to "users" role.
Now, when you have users, passwords and groups in database you can
configure Glassfish to use those tables in JDBC realm.
Now, when user is accessing session bean that can be accessed only by
"users" - it will check if given user belongs to "users" role. It will
check user login and password in user table and group in group table
and check if user belong to group that is mapped to "users" role (as I
said it can be 1:1).
Now, inside your session beans' method you can be sure that user is
authorized and authenticated. Now, you can check exactly who is
accessing it by checking this in session bean context. Now you know
who exactly is asking for result and you can use user login to
parametrize database query.
When user will try to tweak client code and pretend to be someone else
- server will recognize it and will not let him/her to access your
method.
> > Did you read at least one book about Java EE or EJB
> > security?
>
> No, just the specs and tutorial. From that I understood you can authenticate user against JEE and then grant or deny him access to individual methods.
You really should read books about Java EE technology before using it,
because you will loose 10x more time experimenting and trying to force
opened doors.
> However I do not think this is something I need as all users would have server role "user" and can execute (almost) all methods. The difference is in the resultset - as for example "manager" can see more records than "janitor".
That is exactly what you can do with Java EE build in
security/authentication/authorization.
> Therefore if "janitor" somehow manages to find out database user id of "manager" and modify client to send it.. he has completely different view at data. Not desirable. Do you know what I mean?
"janitor" can manage database user id (login) of "manager" but as long
as he/she does not know what the password is - he/she can only dream
about accessing data.
Regards,
Witold Szczerba