Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=sFClCo5wz1p1KcQ2mSM+Kaqe7FRTW5IjHa3Aq55Z0f+28yUUySYHykpNvuSUOUAFsY2hlnZv9loUnXxKJU/dfJoBg0H4wsKnvSDY+X+SQ1wNENpvLetVFcpfK5/EN+Vyj9Zq5sUp6FBmZiG2n1X7Q3igP1DqTxet1Bwd8asRB30=
  ;
Message-Id: <99D0D013-6F35-4F2D-BE98-64D9ED3C0E36@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: user@geronimo.apache.org
In-Reply-To: <16844548.post@talk.nabble.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: JAAS with a standalone client
Date: Thu, 24 Apr 2008 00:03:57 -0700
References: <16824275.post@talk.nabble.com>
 <D1089210-37E1-4F6C-BF0A-27290C8E154A@yahoo.com>
 <16844548.post@talk.nabble.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.
>