On Apr 23, 2008, at 11:16 PM, maho77 wrote:
djencks wrote:
Well, I kind of hope you can't get the server side Subject into your
client :-). Could I suggest that doing so might not be appropriate
from a security standpoint? You don't really know what other
sensitive info might have been added to the Subject. Also, I think
you would be tying your client to a particular login module which
might not be an appropriate coupling.
What I would suggest considering is to have a server component (ejb?)
that maps the principals in the Subject to a set of (String) roles
that are sent back to the client, and that you base the UI stuff on
these roles. It's pretty silly that there isn't a getUserRoles()
call in the ee specs but that is what we have to live with now.
Anyway I think this would prevent accidentally sending sensitive info
to the client, and provide some decoupling between the specific login
module you happen to be using now and your client.
There might be something I've overlooked here, so feel free to try to
change my mind :-)
thanks
david jencks
Hello,
I currently use a login module that calls a stateless bean with the
user
credentials. The bean itself takes the user that accesses the bean a
return
all his groups to the client. The client turns the groups into
principals
and so on
This works, but I don't like this way.
On a client there is a need to hide UI elements from the user in
some ways,
The user wants to login one time to the client.
Than I have to hide some UI elements e.g. for the whole admin
module, if the
user has no access rights for it. And further I only need this
information
for hiding UI elements. The logic happens on the geronimo server and
the ejb
components are secured with roles. That means if I want to access to
the
logic, the server security handles the access, not the client. The
client
only has to know the user credentials and the realm.
Are you wishing for something like the server-side jacc system on your
client? I've wanted that too, but at the moment I tend to think
that storing roles as principals is not the best plan. I lean toward
having only an identification principal in the Subject and keeping
track of roles separately. AFAIK this doesn't fit very well into any
current java specs, but is pretty much what RBAC models deal with.
I know it's a philosophical problem. So see this reply just as a
statement,
from my point of view. I have no web client that's the problem I
have ;-)
At the risk of being too repetitive...
I think that sending the server-side subject back to a client is apt
to be more than a philosophical problem. In general, you don't know
what information other than the principals you are interested in may
be in the subject. For instance in geronimo if you want to access a
remote secured web service you put the credentials for the web service
in the Subject. These may be credentials for the server to access the
web service, not for the user of the server. Leaking these to the
user/client program could be a serious security violation. In order
to do this, you would need verification that the client program is
authorized to get the credentials: presumably this would involve
signing the code and communicating this somehow to the server.
Instead of this likely-to-be-risky exposure, if you just make the user
roles available to the client, you are unlikely to be sending
particularly sensitive information. Could I ask what kind of security
system you are using on the client that requires principals?
many thanks
david jencks
Have a nice day
Mark
--
View this message in context:
http://www.nabble.com/JAAS-with-a-standalone-client-tp16824275s134p16844548.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
