Re: CORBA and GSSUP fix -- please review
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:[EMAIL PROTECTED]: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
The [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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. :)
Re: CORBA and GSSUP fix -- please review
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. :)
Re: CORBA and GSSUP fix -- please review
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. :)
Re: CORBA and GSSUP fix -- please review
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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
CORBA and GSSUP fix -- please review
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. :)
