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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
