The current cvs code should be working as Oleg suggests as there
is no attempt to wrap the Principal obtained from the Subject that
was created by a LoginModule. I don't know that this behavior will
exist in the future for a couple of reasons:
1. This seems like a security hole since I can write a LoginModule that creates
mutable Principals that would allow someone down the line to change the
Principal identity.
2. A LoginModule operates in the operation envionrment domain in terms of
its notion of security roles/user ids. It is talking directly to an LDAP server,
NT domain controller, Kerberos server, etc. that are part of the operation
envionrment security infrastructure. An ejb describes its security in terms
of logical roles that need not exist directly in the operation environment.
>From the 1.1 EJB spec:
<spec>
15.3.1 Security roles
The Application Assembler can define one or more security roles
in the deployment descriptor. The Application Assembler then
assigns groups of methods of the enterprise beans' home and remote
interfaces to the security roles to define the security view of
the application.
Because the Application Assembler does not, in general, know the
security environment of the operational environment, the security
roles are meant to be logical roles (or actors), each representing
a type of user that should have the same access rights to the application.
</spec>
Now we often do know that there is a direct mapping because we are
wearing all of the EJB spec role hats. In general though, there is a mapping
between the ejb-jar.xml security roles and the LoginModule authenticated
Principal. This mapping is what the RealmMapping interface abstraction
is for. Currently this is where you could ensure that a certain type of
Principal object is returned by the getCallerPrincipal() method. However,
if we wanted to be paranoid about not allowing custom RealmMapping
instances to introduce security holes, the ejb container would wrap the
Principal obtained from the RealmMapping into a security proxy that
only implemented the Principal interface and delegate these methods
to the Principal returned by the RealmMapping instance.
In general the approach your looking to adopt is not portable because it
requires an ejb context to return subinterface of Principal that you may
not be able to introduce into an application server. Is there another way
to introduce the additional authentication/authorization you have attached
to the LoginModule Principal?
----- Original Message -----
From: "Cor Hofman" <[EMAIL PROTECTED]>
To: "JBoss-User" <[EMAIL PROTECTED]>
Sent: Monday, February 26, 2001 12:01 AM
Subject: RE: [jBoss-User] Problems with Principal class propagation
> Hi Scott,
>
> Looks like a plan. I also saw a post of Oleg, which
> suggests it might be a bug in the version of JBoss
> I use. So the first thing I am going to do is follow
> his hint and try the most current CVS version, which
> will contain your update as well I guess. This does not
> mean that I do not value your remarks. Om the contrairy.
> The reason that I am follwing Oleg's hint is that I see
> my own principal type being available within the session
> bean. This implies that the the Principal was correctly
> received and used by the application server initially.
> It is only in the next step (calling the entity bean from the
> session bean) where it goes wrong.
> Furthermore I had a look at the JAASSecurityManagerService
> and I could not find anything specific in there about using
> SimplePrincipal.
> Hope you don't mind with the work you put in and please correct
> me if I am on the wrong path here.
>
> Greetings
>
> Cor.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark
> Sent: Saturday, February 24, 2001 20:44
> To: JBoss-User
> Subject: Re: [jBoss-User] Problems with Principal class propagation
>
>
> You would have to create an implementation of the RealmMapping interface.
> One way would be to create a subclass of
> org.jboss.security.plugins.JaasSecurityManager
> and override the getPrincipal(Principal) method. You then need to do (b)
> which
> right now requires that you create a JMX mbean and install your RealmMapping
> instance into the JNDI namespace at the location you use for the container
> role-mapping-manager element, which in your case is: java:/jaas/companion
>
> I'm merging the new contrib security stuff to the core this weekend and this
> will
> allow to you specific which class implements RealmMapping using the
> existing JaasSecurityManagerService mbean so that you won't have to create
> your own mbean.
>
> ----- Original Message -----
> From: "Cor Hofman" <[EMAIL PROTECTED]>
> To: "JBoss-User" <[EMAIL PROTECTED]>
> Sent: Saturday, February 24, 2001 4:26 AM
> Subject: RE: [jBoss-User] Problems with Principal class propagation
>
>
> > Scott,
> >
> > What do you mean by "own implementation of
> org.jboss.security.RealmMapping"
> > a) Replace the org.jboss.security.RealmMapping and recompile JBoss.
> > b) A configuration option of JBoss, which allows me to specify which
> > class implements ReamMapping.
> >
> > Greetings,
> >
> > Cor.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark
> > Sent: Saturday, February 24, 2001 09:54
> > To: JBoss-User
> > Subject: Re: [jBoss-User] Problems with Principal class propagation
> >
> >
> > You would have to create your own implemention of
> > org.jboss.security.RealmMapping
> > and install that as the role-mapping-manager. The RealmMapping instance is
> > what
> > determines the instance of Principal that is returned by
> > getCallerPrincipal(). You can't
> > rely on the type of Principal that is established by your LoginModule to
> be
> > what is
> > returned by the getCallerPrincipal() method as the container can choose to
> > insert a
> > proxy that only publishes the java.security.Principal interface to prevent
> > changes to the
> > Principal established by the LoginModule.
> >
> > The org.jboss.security.RealmMapping#getPrincipal( Principal ) method is
> > where you
> > would map the java.security.Principal into your particular instance.
> >
> > ----- Original Message -----
> > From: "Cor Hofman" <[EMAIL PROTECTED]>
> > To: "JBoss User list" <[EMAIL PROTECTED]>
> > Sent: Friday, February 23, 2001 11:18 PM
> > Subject: [jBoss-User] Problems with Principal class propagation
> >
> >
> > > Hi,
> > >
> > > I implemented my own Principal class to add some extra
> > > authorization methods.
> > >
> > > When I perform a the login and call a session bean everything looks
> fine.
> > > The getCallerPrincipal() inside a sessionbean returns
> > > my own Principal. This session bean then calls an entity bean.
> > > When the entity bean call getCallerPrinciple() it returns an original
> > > SimplePrincipal instance. I would expect the entity bean to return
> > > my own Principal as well. Why isn't that happening?
> > > I expected the new Principal class to be propagated automatically.
> > >
> > > I use a PRE2.1 build from the beginning of january.
> > >
> > > For both the session bean and the entity bean I added the famous
> > > two lines:
> > >
> > > <role-mapping-manager>java:/jaas/companion</role-mapping-manager>
> > > <authentication-module>java:/jaas/companion</authentication-module>
> > >
> > > to the container types I use for the session and the entity bean
> > > (in standardJboss.xml).
> > >
> > > I also modified the auth.conf to contain a companion section.
> > >
> > > companion {
> > > org.companion.security.ServerLoginModule required;
> > > };
> > >
> > > Furthermore I added this to the client auth.conf
> > >
> > > companion
> > > {
> > > org.companion.security.ClientLoginModule required
> > multi-threaded="true";
> > > };
> > >
> > > Any suggestion or hint on how to tackle this one are ver much
> appreciated.
> > >
> > > Greetings,
> > >
> > > Cor Hofman
> > >
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > List Help?: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > List Help?: [EMAIL PROTECTED]
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > List Help?: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
