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/10 05:39:14 UTC

CORBA and GSSUP fix -- please review

So it turns out our GSSUP token encoder set the username to
username@domain and the GSSUP token decoder did not lop off the
@domain part, so Geronimo could not talk to itself using GSSUP.

I changed the token encoder to just pass the username straight through
-- there is a separate field in the token that holds the domain, after
all, so mangling the username did not seem to make much sense.

Just want to make a note of this in case someone thinks it should be
changed the other way (that is, the GSSUP token encoder should send
username@domain and the GSSUP token decoder should lop off and ignore
the @domain part, or compare the @domain to the domain that is sent in
the other field).

Thanks,
    Aaron

P.S. Actually the GSSUP token encoder set the username to
domain@domain due to an additional bug in the dynamic GSSUP
configuration, so I gather no one's actually used this code before. 
:)

Re: CORBA and GSSUP fix -- please review

Posted by "Jeppe Sommer (Trifork)" <js...@trifork.com>.
The username@domain form is also what we use in the Trifork Server/ORB...

Andy Piper wrote:

> At 03:51 PM 2/10/2006, Aaron Mulder wrote:
>
>> Just to be clear, I'm talking about GSSUP authentication (where the
>> client sends a token containing a username and password and an encoded
>> domain name) not one of the principal name strategies (e.g. ITT*).
>>
>> Jeppe, I'm not clear whether the GSS Name Form you're describing
>> applies to the username in a username/password/domain token or the
>> principal name in a principal name token.  It would seem weird to set
>> the username to username@domain when the same token already contains a
>> domain name, in effect.
>
>
> "The format of the name passed in the username field depends on the 
> authentication
> domain. If the mechanism identifier of the target domain is GSSUP, 
> then the format of
> the username shall be a Scoped-Username (with name_value) as defined 
> in "Scoped-
> Username GSS Name Form" on page 26-15"
>
> So it applies, although stripping the domain seems legal to me.
>
> andy

Re: CORBA and GSSUP fix -- please review

Posted by Andy Piper <an...@bea.com>.
At 03:51 PM 2/10/2006, Aaron Mulder wrote:
>Just to be clear, I'm talking about GSSUP authentication (where the
>client sends a token containing a username and password and an encoded
>domain name) not one of the principal name strategies (e.g. ITT*).
>
>Jeppe, I'm not clear whether the GSS Name Form you're describing
>applies to the username in a username/password/domain token or the
>principal name in a principal name token.  It would seem weird to set
>the username to username@domain when the same token already contains a
>domain name, in effect.

"The format of the name passed in the username field depends on the 
authentication
domain. If the mechanism identifier of the target domain is GSSUP, 
then the format of
the username shall be a Scoped-Username (with name_value) as defined 
in "Scoped-
Username GSS Name Form" on page 26-15"

So it applies, although stripping the domain seems legal to me.

andy

Re: CORBA and GSSUP fix -- please review

Posted by Andy Piper <an...@bea.com>.
At 05:14 PM 2/10/2006, Aaron Mulder wrote:
>Sorry, you're crediting me with a lot more CORBA knowledge than I
>deserve.  :)  In particular, I'm not sure what the right IIOP URL or
>corbaname URL should be.  Let me give you a more specific scenario:
>
>Let's say I have a session bean running in Geronimo, so the Geronimo
>side of the picture looks like this:
>
>CORBA naming service: localhost:1050 (or
>corbaloc::localhost:1050/NameService), with SSL enabled
>EJB name in naming service: MySessionBean
>EJB TSS listening for SSL on localhost:1055

So assuming G supports corbaname (which it should) the url for this 
would look like so:

corbaname:iiop:1.2@localhost:1050#MySessionBean

>Now I have a web app deployed in WebLogic with an ejb-ref in web.xml
>pointing to the correct home and remote interface for this session
>bean, but with no EJB link.  So I'm assuming I need to put something
>in weblogic.xml in order to resolve this ejb-ref to point to the CORBA
>EJB above.  What does that configuration block look like?

I'm not sure I fully understand, but there is nothing special about 
CORBA internally. A weblogic.xml entry might look like this:

      <reference-descriptor>
         <ejb-reference-description>
           <ejb-ref-name>
             j2ee/interop/demo/tester
           </ejb-ref-name>
           <jndi-name>
             ejb/j2ee/interop/demo/tester
           </jndi-name>
         </ejb-reference-description>
      </reference-descriptor>

The JNDI name could be a corbaname URL if the EJB is remote.

>Also, if security is enabled for that session bean in Geronimo, so I
>want to pass my username and password that I used for the WebLogic web
>app across to the Geronimo EJB using GSSUP, and Geronimo requires that
>the GSSUP token contain the domain name (or target name) of
>"geronimo-properties-realm" along with the username and password, how
>would I set that up in weblogic.xml?

I'm not sure we allow you to control this :). Security settings can 
be set per ejb in the descriptor, but I don't think the target is included.

>Finally, let's say the EJB is running in WebLogic and the web app
>running in Geronimo:
>
>  - What naming service corbaloc would I use on the Geronimo side to
>point to WebLogic's naming service?  Would it be
>"corbaloc::localhost:7001/NameService"?

Yes, but better to use corbaname above.

>  - What is the name of the EJB inside the WebLogic naming service?
>e.g. is it one of the ejb-name or the jndi-name for that EJB, or is
>there some other setting for it?

Its just the jndi-name.

>  - Is it OK to specify that SSL should be used to contact the naming
>service and/or the EJB?  Does anything need to be done on the WebLogic
>side to enable that?  (Other than I guess any URLs would go over the
>SSL listen port not the regular WebLogic listen port.)

I would recommend you start without security first :) The simplest 
way to force the use of SSL is to switch off the main listen port. 
You can also fiddle with the EJB security descriptors, although this 
is not documented.

>  - If the EJB is secured on the WebLogic side and I want to pass my
>Geronimo login username and password to WebLogic via GSSUP, does
>WebLogic expect any particular target name or domain name to come with
>the username/password in the GSSUP authentication token?

No. I think we will strip the target name or use it as the security 
realm name.

andy

Re: CORBA and GSSUP fix -- please review

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Andy,

Sorry, you're crediting me with a lot more CORBA knowledge than I
deserve.  :)  In particular, I'm not sure what the right IIOP URL or
corbaname URL should be.  Let me give you a more specific scenario:

Let's say I have a session bean running in Geronimo, so the Geronimo
side of the picture looks like this:

CORBA naming service: localhost:1050 (or
corbaloc::localhost:1050/NameService), with SSL enabled
EJB name in naming service: MySessionBean
EJB TSS listening for SSL on localhost:1055

Now I have a web app deployed in WebLogic with an ejb-ref in web.xml
pointing to the correct home and remote interface for this session
bean, but with no EJB link.  So I'm assuming I need to put something
in weblogic.xml in order to resolve this ejb-ref to point to the CORBA
EJB above.  What does that configuration block look like?

Also, if security is enabled for that session bean in Geronimo, so I
want to pass my username and password that I used for the WebLogic web
app across to the Geronimo EJB using GSSUP, and Geronimo requires that
the GSSUP token contain the domain name (or target name) of
"geronimo-properties-realm" along with the username and password, how
would I set that up in weblogic.xml?

Finally, let's say the EJB is running in WebLogic and the web app
running in Geronimo:

 - What naming service corbaloc would I use on the Geronimo side to
point to WebLogic's naming service?  Would it be
"corbaloc::localhost:7001/NameService"?

 - What is the name of the EJB inside the WebLogic naming service? 
e.g. is it one of the ejb-name or the jndi-name for that EJB, or is
there some other setting for it?

 - Is it OK to specify that SSL should be used to contact the naming
service and/or the EJB?  Does anything need to be done on the WebLogic
side to enable that?  (Other than I guess any URLs would go over the
SSL listen port not the regular WebLogic listen port.)

 - If the EJB is secured on the WebLogic side and I want to pass my
Geronimo login username and password to WebLogic via GSSUP, does
WebLogic expect any particular target name or domain name to come with
the username/password in the GSSUP authentication token?

Thanks,
    Aaron

On 2/10/06, Andy Piper <an...@bea.com> wrote:
> At 03:51 PM 2/10/2006, Aaron Mulder wrote:
> >Andy, is there some good documentation on exposing an EJB via CORBA in
> >WebLogic, or configuring an EJB reference to connect to a remote CORBA
> >EJB?  I might as well try a WebLogic-to-Geronimo test to help resolve
> >this.
>
> Its enabled by default. In theory just point at the right IIOP URL
> and you are golden. Unfortunately vendors' opinions differ on what
> each server should actually do in ejb-ejb calls. We have a long
> internal doc for configuring WAS for WLS-WAS interop since its
> particularly tricky with security switched on.
>
> As to configuring an EJB ref, any conforming implementation should
> support a ref with a corbaname URL inside.
>
> andy
>
>

Re: CORBA and GSSUP fix -- please review

Posted by Andy Piper <an...@bea.com>.
At 03:51 PM 2/10/2006, Aaron Mulder wrote:
>Andy, is there some good documentation on exposing an EJB via CORBA in
>WebLogic, or configuring an EJB reference to connect to a remote CORBA
>EJB?  I might as well try a WebLogic-to-Geronimo test to help resolve
>this.

Its enabled by default. In theory just point at the right IIOP URL 
and you are golden. Unfortunately vendors' opinions differ on what 
each server should actually do in ejb-ejb calls. We have a long 
internal doc for configuring WAS for WLS-WAS interop since its 
particularly tricky with security switched on.

As to configuring an EJB ref, any conforming implementation should 
support a ref with a corbaname URL inside.

andy

Re: CORBA and GSSUP fix -- please review

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Just to be clear, I'm talking about GSSUP authentication (where the
client sends a token containing a username and password and an encoded
domain name) not one of the principal name strategies (e.g. ITT*).

Jeppe, I'm not clear whether the GSS Name Form you're describing
applies to the username in a username/password/domain token or the
principal name in a principal name token.  It would seem weird to set
the username to username@domain when the same token already contains a
domain name, in effect.

Andy, is there some good documentation on exposing an EJB via CORBA in
WebLogic, or configuring an EJB reference to connect to a remote CORBA
EJB?  I might as well try a WebLogic-to-Geronimo test to help resolve
this.

Thanks,
    Aaron

On 2/10/06, Andy Piper <an...@bea.com> wrote:
> I don't believe it's actually required to provide the username in the
> client identity field if you have a password. You can simply provide
> an auth token containing both username and password and set the
> identity token to ITTAbsent. We (WLS) only fallback on
> ITTPrincipleName if there is no password available, in which case you
> have to have established a trust relationship and perform identity
> assertion. If you use the principle name token then the decoder
> should be able to understand the attached scope if any - removing it
> on the encoding side does not seem right to me.
>
> andy
>
>
> At 09:57 AM 2/10/2006, Jeppe Sommer (Trifork) wrote:
> >According to the CORBA 3.0.3 spec (and I believe the original CSIv2
> >spec says the same):
> >Scoped-Username GSS Name Form
> >The scoped-username GSS name form is defined as follows, where name_value and
> >name_scope contain a sequence of 1 or more UTF8 encoded characters.
> >
> >scoped-username ::= name_value | name_value@name_scope | @name_scope
> >
> >The '@' character shall be used to delimit name_value from
> >name_scope. All nondelimiter
> >instances of '@' and all non-quoting instances of '\' shall be quoted with an
> >immediately-preceding '\'. Except for these cases, the quoting
> >character, '\', shall not be
> >emitted within a scoped-username.
> >
> >This suggests that the right way to fix this is to make the decoder
> >tolerant to both name and name@domain. I don't known how the third
> >variant  - just @domain - is to be interpreted though.
> >
> >I'm also uncertain how an empty domain part is to be interpreted. To
> >be on the safe side, I would suggest always encoding the full form
> >(name@domain) and live with the redundancy.
> >
> >Cheers,
> >/Jeppe
> >
> >Aaron Mulder wrote:
> >>
> >>So it turns out our GSSUP token encoder set the username to
> >>username@domain and the GSSUP token decoder did not lop off the
> >>@domain part, so Geronimo could not talk to itself using GSSUP.
> >>
> >>I changed the token encoder to just pass the username straight through
> >>-- there is a separate field in the token that holds the domain, after
> >>all, so mangling the username did not seem to make much sense.
> >>
> >>Just want to make a note of this in case someone thinks it should be
> >>changed the other way (that is, the GSSUP token encoder should send
> >>username@domain and the GSSUP token decoder should lop off and ignore
> >>the @domain part, or compare the @domain to the domain that is sent in
> >>the other field).
> >>
> >>Thanks,
> >>     Aaron
> >>
> >>P.S. Actually the GSSUP token encoder set the username to
> >>domain@domain due to an additional bug in the dynamic GSSUP
> >>configuration, so I gather no one's actually used this code before.
> >>:)
> >>
>
>

Re: CORBA and GSSUP fix -- please review

Posted by Andy Piper <an...@bea.com>.
I don't believe it's actually required to provide the username in the 
client identity field if you have a password. You can simply provide 
an auth token containing both username and password and set the 
identity token to ITTAbsent. We (WLS) only fallback on 
ITTPrincipleName if there is no password available, in which case you 
have to have established a trust relationship and perform identity 
assertion. If you use the principle name token then the decoder 
should be able to understand the attached scope if any - removing it 
on the encoding side does not seem right to me.

andy


At 09:57 AM 2/10/2006, Jeppe Sommer (Trifork) wrote:
>According to the CORBA 3.0.3 spec (and I believe the original CSIv2 
>spec says the same):
>Scoped-Username GSS Name Form
>The scoped-username GSS name form is defined as follows, where name_value and
>name_scope contain a sequence of 1 or more UTF8 encoded characters.
>
>scoped-username ::= name_value | name_value@name_scope | @name_scope
>
>The '@' character shall be used to delimit name_value from 
>name_scope. All nondelimiter
>instances of '@' and all non-quoting instances of '\' shall be quoted with an
>immediately-preceding '\'. Except for these cases, the quoting 
>character, '\', shall not be
>emitted within a scoped-username.
>
>This suggests that the right way to fix this is to make the decoder 
>tolerant to both name and name@domain. I don't known how the third 
>variant  - just @domain - is to be interpreted though.
>
>I'm also uncertain how an empty domain part is to be interpreted. To 
>be on the safe side, I would suggest always encoding the full form 
>(name@domain) and live with the redundancy.
>
>Cheers,
>/Jeppe
>
>Aaron Mulder wrote:
>>
>>So it turns out our GSSUP token encoder set the username to
>>username@domain and the GSSUP token decoder did not lop off the
>>@domain part, so Geronimo could not talk to itself using GSSUP.
>>
>>I changed the token encoder to just pass the username straight through
>>-- there is a separate field in the token that holds the domain, after
>>all, so mangling the username did not seem to make much sense.
>>
>>Just want to make a note of this in case someone thinks it should be
>>changed the other way (that is, the GSSUP token encoder should send
>>username@domain and the GSSUP token decoder should lop off and ignore
>>the @domain part, or compare the @domain to the domain that is sent in
>>the other field).
>>
>>Thanks,
>>     Aaron
>>
>>P.S. Actually the GSSUP token encoder set the username to
>>domain@domain due to an additional bug in the dynamic GSSUP
>>configuration, so I gather no one's actually used this code before.
>>:)
>>

Re: CORBA and GSSUP fix -- please review

Posted by "Jeppe Sommer (Trifork)" <js...@trifork.com>.
According to the CORBA 3.0.3 spec (and I believe the original CSIv2 spec 
says the same):

    *Scoped-Username GSS Name Form*
    The scoped-username GSS name form is defined as follows, where
    *name_value* and
    *name_scope* contain a sequence of 1 or more UTF8 encoded characters.

    *scoped-username ::= name_value | name_value@name_scope | @name_scope*

    The '@' character shall be used to delimit *name_value* from
    *name_scope*. All nondelimiter
    instances of '@' and all non-quoting instances of '\' shall be
    quoted with an
    immediately-preceding '\'. Except for these cases, the quoting
    character, '\', shall not be
    emitted within a scoped-username.

This suggests that the right way to fix this is to make the decoder 
tolerant to both *name* and *name@domain*. I don't known how the third 
variant  - just *@domain* - is to be interpreted though.

I'm also uncertain how an empty domain part is to be interpreted. To be 
on the safe side, I would suggest always encoding the full form 
(name@domain) and live with the redundancy.

Cheers,
/Jeppe

Aaron Mulder wrote:

>So it turns out our GSSUP token encoder set the username to
>username@domain and the GSSUP token decoder did not lop off the
>@domain part, so Geronimo could not talk to itself using GSSUP.
>
>I changed the token encoder to just pass the username straight through
>-- there is a separate field in the token that holds the domain, after
>all, so mangling the username did not seem to make much sense.
>
>Just want to make a note of this in case someone thinks it should be
>changed the other way (that is, the GSSUP token encoder should send
>username@domain and the GSSUP token decoder should lop off and ignore
>the @domain part, or compare the @domain to the domain that is sent in
>the other field).
>
>Thanks,
>    Aaron
>
>P.S. Actually the GSSUP token encoder set the username to
>domain@domain due to an additional bug in the dynamic GSSUP
>configuration, so I gather no one's actually used this code before. 
>:)
>  
>