You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2006/02/06 16:41:00 UTC
Default Security Principal & Role Mapping
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>
Re: Default Security Principal & Role Mapping
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@yahoo.com> 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 <da...@yahoo.com> 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>
> >>
> >>
>
>
Re: Default Security Principal & Role Mapping
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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>
>>
>>
Re: Default Security Principal & Role Mapping
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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? If so, do they
need qualifying roles for the EJB they're actually invoking, or just
for calls out to other EJBs from there?
Thanks,
Aaron
<tss:compoundSecMechTypeList>
<tss:compoundSecMech>
<tss:sasMech>
<tss:identityTokenTypes>
<tss:ITTPrincipalNameGSSUP
principal-class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>
<tss:ITTDistinguishedName/>
</tss:identityTokenTypes>
</tss:sasMech>
</tss:compoundSecMech>
</tss:compoundSecMechTypeList>
On 2/6/06, David Jencks <da...@yahoo.com> 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>
>
>
Re: Default Security Principal & Role Mapping
Posted by David Jencks <da...@yahoo.com>.
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>