geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: CORBA and GSSUP fix -- please review
Date Fri, 10 Feb 2006 15:51:37 GMT
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 <andyp@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.
> >>:)
> >>
>
>

Mime
View raw message