avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Security - AAA implementation [was RE: DefaultRoleManager in Cor nerstone]
Date Fri, 18 Jan 2002 00:41:00 GMT
Peter,

Perhaps there is misunderstading all round.

I like you previous email re the way a user 'comes in'  PKI cleary is 
more trustworthy as a remote connection mechanism than id/password. 
 Incidentally, if the Biometric scanner is not directly wired to the 
machine wishing to autheticate, it is hackable mechanism. It is 
vulnerable to a 'playback' attack.  The Phoenix kernal would have to 
completely trust the remote biometric validator and know that it had not 
in part or in whole been hacked.  That's also true of PKI, but with say 
the more expensive iButton where the private key cannot be copied, it is 
largely foolproof ( 
http://www-users.rwth-aachen.de/dierk.bolten/pam_ibutton.html ). 
Foolproof, that is, ignoring 'rubber hose' code-breaking.  Last on this 
subject in places where PIN is used to authenticate smart card 
electronic _cash_ cards ('Proton' in Belgium), the owner of the card has 
to trust the vendors machine to not take more than it is displaying on 
the screen.

Anyway, irrespective of J2EE choices, I see the model as ...

User has n-1 Group
Group has 0-n Group
Group has 0-n Role
Role has MinimumPrincipalLevel ( say 1=id&password, 2=trusted biometric 
/ PKI signed text )

Of course with permissions, we are essentially seeing is a certain user 
has a certain role.  With the model above there could be multiple 
navigations to a role.

Regards,

- Paul H

>On Fri, 18 Jan 2002 10:29, MCCAY,LARRY (HP-NewJersey,ex2) wrote:
>
>>>I'd be much keener on 'group' than 'role' per se.  A user
>>>belongs to one
>>>or more groups.  Groups can belong to groups.  Some groups can be
>>>mandatory and considered as roles.
>>>I can't remember where I first encoutered this design.
>>>Nearly a decade
>>>on AS/400's I guess.
>>>
>>Perhaps, the RoleManager should really be PermissionManager - in the end a
>>role can be represented by a permission collection.  A permission
>>collection can be associated with any arbitrary principal, including
>>identity and group principals.  Within the spirit of J2EE we can still
>>support an abstraction of role-based access control - implemented without
>>any actual role per se.
>>
>
>So Role would be another principle? In effect you would do a mapping from 
>"identity" principle to "ROle" principle and then just use that? I like that.
>




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message