Scott,
I see that your understending of security issues is much better than mine.
So, after my answer to your question "what is security view?",
which approach would you prefer:
one Subject per security view or
one Subject globally (of course, for the given user)?
If the latter, how to distinguish Principals, which belongs to different
security views?
How to separate Principal-principals from Principal-roles?
To introduce additional interface Role extending Principal?
Regards,
Oleg
On Friday 15 December 2000 03:31, Scott M Stark wrote:
> ----- Original Message -----
> From: "Oleg Nitz" <[EMAIL PROTECTED]>
> To: "jBoss Developer" <[EMAIL PROTECTED]>
> Sent: Thursday, December 14, 2000 4:56 PM
> Subject: Re: [jBoss-Dev] Was: [jBoss-User] Security Walkthrough/How
> To/Tutorial, first cut
>
> > > > New mapping "EJB security -> JAAS" was born.
> > >
> > > I agree with this change, but JAAS is Subject based, not Principal
> > > based. My view of JAAS is that the Subject is the key object and its
> > > contains one or more Principals + public/private creditials. Principals
> > > are not smart objects. They are strings, X509 certs, etc. They can only
> > > compare agaist each other and give you a string name.
> >
> > Let's read JAAS notions definitions rather than look at common examples.
> > Otherwise the task of "EJB security -> JAAS" mapping can't be solved.
> > If Principals are string, Public Credentials are public keys and Private
> > Credentials are private keys, then we should just give up.
>
> My point is that since a Principal can be anything, all we should be
> relying on is its public interface. Trying to place any functionallity
> other than equality in a Principal will simply make it difficult to
> integrate different types of Principals.
>
> So say I have a security policy that requires users be identified via their
> X509 certs. The declarative EJB security model only supports roles as
> string names in the deployment descriptor(correct me if I'm wrong). There
> needs to be a bridge between these two domains. If the set of role names is
> uniquely a function of the certs properties, then the CertLoginModule can
> bind the Principal roles at login time. If this mapping needs to be more
> dynamic the CertLoginModule could add a java.security.acl.Group as a
> Principal:
>
> Principal ejbRoles = new java.security.acl.Group()
> {
> public String getName() { return "EJBRoleMapping"; }
> public boolean equals(Object obj) { ... }
> ...
> public boolean addMember(Principal user) { ... }
> public boolean removeMember(Principal user) { ... }
> public boolean isMember(Principal member) { ... }
> }
>
> and then the is user in role check could be(in some strange psuedo code):
>
> Subject s = ...
> Group ejbRoles = (Group) s.getPrincipals(java.security.acl.Group.class);
> Set methodPermissions;
> foreach ejbRoleName in methodPermissions
> boolean hasRole = ejbRoles.isMember(ejbRoleName);
