Hi Oleg, I'm going to breakup my followup comments across a couple mails to
reduce the signal to noise ratio.
> > > Principal for EJB security should contain a set of roles as its
> > > attribute.
> >
> > Here I don't agree. The roles are a subset of the Principals associated
> > with the Subject executing the EJB.
> 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.
> Okay, how do you define to which security view the given Principal-principal
> or Principal-role belongs?
> Either we need Principal.getSecurityView() method, i.e. we go outside of the
> public interfaces, or we need different classes for different security views,
> which is in general acceptable, but kills the idea of parameterized class
> which serves to several security views.
>
> > Neither Subject nor Principal support
> > the notion of attributes so you would have to go outside of the public
> > interfaces to implement this.
> This is what Edward proposes.
>
I'm not clearly understanding what you mean by a security view. In the current
architecture
The JaasSecurityManager handles the
securityManager.isValid( principal, credential )
realmMapping.doesUserHaveRole( principal, methodPermissions )
calls made by the SecurityInterceptor and uses the beanName as the LoginContext name.
Is
the beanName the security view?
Why can't both of these call be satisfied via:
Subject s = currentLoginContext.getSubject();
boolean isValid = s.getPrincipals().contains(principal);
boolean hasRole = s.getPrincipals().containsAll(methodPermissions);
Any Principal-Principal and Principal-Role mapping could be done by a
EJBPrincipalLoginModule.
