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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | @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 [EMAIL PROTECTED] 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
> >([EMAIL PROTECTED]) and live with the redundancy.
> >
> >Cheers,
> >/Jeppe
> >
> >Aaron Mulder wrote:
> >>
> >>So it turns out our GSSUP token encoder set the username to
> >>[EMAIL PROTECTED] 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
> >>[EMAIL PROTECTED] 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
> >>[EMAIL PROTECTED] due to an additional bug in the dynamic GSSUP
> >>configuration, so I gather no one's actually used this code before.
> >>:)
> >>
>
>
