OK. If you guys get a chance, can you double-check my writeup of how security for CORBA relates to EJB security? Here's the page it's on, and particularly section 17.2.1.5 (and the enclosed Example 17.1):
http://chariotsolutions.com/geronimo/corba-ejb-server.html Thanks, Aaron On 2/6/06, David Jencks <[EMAIL PROTECTED]> wrote: > > On Feb 6, 2006, at 9:38 AM, Aaron Mulder wrote: > > > Great. > > > > So my next question is CORBA. If a CORBA client calls in to an EJB, > > and we have it configured to accept principals the caller provides > > (see below) then does role mapping (as configured in openejb-jar.xml) > > apply to the principals we grant the CORBA caller? > > yes > > If so, do they > > need qualifying roles for the EJB they're actually invoking, > > yes > > or just > > for calls out to other EJBs from there? > that too. > > > > Thanks, > > Aaron > > > > <tss:compoundSecMechTypeList> > > <tss:compoundSecMech> > > <tss:sasMech> > > <tss:identityTokenTypes> > > <tss:ITTPrincipalNameGSSUP > > principal- > > class="org.apache.geronimo.security.realm.providers.GeronimoUserPrinci > > pal"/> > > <tss:ITTDistinguishedName/> > > </tss:identityTokenTypes> > > </tss:sasMech> > > </tss:compoundSecMech> > > </tss:compoundSecMechTypeList> > > so, what you are saying here is, you trust the connection to > establish the authenticity of the identity in the identity token, and > geronimo should take the name from the token and construct a > principal of the specified class and put it in a Subject. The role- > principal mapping will determine which roles that call is in, and > thus the permissions on the ejbs it calls. > > In particular note that the identity token is not logged in using a > login module in the target server: we are trusting the caller's > assertion of identity. > > In my opinion this area of geronimo security needs some more work and > we need to support logging in the asserted identity as well. There > are a lot of details involved here :-) > > thanks > david jencks > > > > > > > On 2/6/06, David Jencks <[EMAIL PROTECTED]> wrote: > >> Assuming the principal classes are the same, the unauthenticated user > >> if given the admin role. > >> > >> IIUC Simon wants to make the default subjects generated by actual > >> login, which might make this point a bit clearer. > >> > >> > >> thanks > >> david jencks > >> > >> On Feb 6, 2006, at 7:41 AM, Aaron Mulder wrote: > >> > >>> If I have a security configuration block like this, is an > >>> unauthenticated user given the Admin role? Or does role mapping > >>> ignore the default principal? > >>> > >>> Thanks, > >>> Aaron > >>> > >>> <security> > >>> <default-principal> > >>> <principal class="..." name="bob" /> > >>> </default-principal> > >>> <role-mappings> > >>> <role name="Admin"> > >>> <principal class="..." name="bob" /> > >>> </role> > >>> </role-mappings> > >>> </security> > >> > >> > >
