JAAS with a standalone client

[maho77 <m....@mvolution.de>]

Hello,
I have a standalone client, no jee-application client. Now I want to login
to the server using JAAS, which works until now. But the only principal I
get from the subject is a server principal. But I need all
GeronimoGroupPricipals and GeronimoUserPrincipals of the authneticated user
in the subject on my client, to enable or disable UI elements. I
investigated in the source code but found no solution for this. Is it
possible to get the GeronimoPricipals to the client or can I get the server
subject in any way?

Currently I have a bean that does the same as the corresponding SQLRealm. It
provides the user and group depending on the user that is currently logged
in. But I want to avoid this solution.

Can you give me an hint?

Mark
-- 
View this message in context: http://www.nabble.com/JAAS-with-a-standalone-client-tp16824275s134p16824275.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.

Re: JAAS with a standalone client

[maho77 <m....@mvolution.de>]

djencks wrote:
> 
> I think that sending the server-side subject back to a client is apt  
> to be more than a philosophical problem. 
>  

As I spoke philosophical problem, I had in mind that I have to deal with a
standalone client instead of a web application.
JAAS works very well in web-apps. I wouldn't have such problems with a
web-app.


djencks wrote:
> 
>  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.
> 

Now I understand. Yes, you're absolutely right. I only saw my simple user
and group principals but there could be more. 
In my case the client should only get the information that belong to him. I
already solved this problem using an stateless bean.


djencks wrote:
> 
> 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?
> 

I use the Eclipse RCP. In version 3.4 JAAS support was introduced. So I use
JAAS on the client side too. What I currently do is mapping roles only to
group principals on server-side. So in my system there is one group for each
role. The groups are my roles. The client gets the groups from a stateless
bean and turns them into my own ClientRolePrincipals. I want the
authorization on the client-side too. The RCP can handle certain parts. I
just want to write my permissions and an own Policy implementation. In the
first step I introduced only realm, username, password authentication. 

I would like to thank you for your comments. Now I think that my stateless
bean solution isn't as bad as I thought.

Mark
-- 
View this message in context: http://www.nabble.com/JAAS-with-a-standalone-client-tp16824275s134p16895769.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.

Re: JAAS with a standalone client

[David Jencks <da...@yahoo.com>]

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.
>

Re: JAAS with a standalone client

[maho77 <m....@mvolution.de>]

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. 

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 ;-)

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.

Re: JAAS with a standalone client

[David Jencks <da...@yahoo.com>]

On Apr 22, 2008, at 6:45 AM, maho77 wrote:

>
> Hello,
> I have a standalone client, no jee-application client. Now I want  
> to login
> to the server using JAAS, which works until now. But the only  
> principal I
> get from the subject is a server principal. But I need all
> GeronimoGroupPricipals and GeronimoUserPrincipals of the  
> authneticated user
> in the subject on my client, to enable or disable UI elements. I
> investigated in the source code but found no solution for this. Is it
> possible to get the GeronimoPricipals to the client or can I get  
> the server
> subject in any way?
>
> Currently I have a bean that does the same as the corresponding  
> SQLRealm. It
> provides the user and group depending on the user that is currently  
> logged
> in. But I want to avoid this solution.
>
> Can you give me an hint?

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

>
> Mark
> -- 
> View this message in context: http://www.nabble.com/JAAS-with-a- 
> standalone-client-tp16824275s134p16824275.html
> Sent from the Apache Geronimo - Users mailing list archive at  
> Nabble.com.
>