Shing Wai ,
Shing Wai Chan wrote On 06/09/06 14:07,:
> Jan Luehe wrote:
>
>> Kedar,
>>
>> Kedar Mhaswade wrote On 06/09/06 00:59,:
>>
>> > Interesting idea.
>> > The less we depend on -D properties, the better.
>> >
>> > Some questions to Jan.
>> >
>> > - Is this stemming from parity with Tomcat alone or
>> > do you see any other need for it?
>>
>> Both. :)
>> By allowing HTTP listeners to be configured for different trust
>> environments, a single appserver domain could be used to host webapps
>> belonging to different trust domains, by designating one or more HTTP
>> listeners for each trust domain, having those listeners feed into
>> their own virtual server, and deploying webapps onto that virtual
>> server.
>>
>> > - Just so that it is clear, we are entertaining something like:
>> > <http-listener id="one" ...>
>> > <ssl .. keystore="ks1" />
>> > </http-listener>
>> > <http-listener id="two" ...>
>> > <ssl .. keystore="ks2" />
>> > </http-listener>
>>
>> Exactly.
>>
>> > where each keystore has keys with different keypasswords,
>>
>> Not sure. I believe even in the current case, it is impossible to
>> protect each key individually, meaning all keys are sharing the
>> the same password that is also used to protect the keystore.
>>
>> > with a currently proposed limitation of same key with which
>> > all the keystores are locked. Is that right?
>>
>> Yes, but this limitation is only temporary, until we have a better
>> understanding of how to specify different passwords for different
>> keystores. We certainly would not want to add a keystore-password
>> attribute to <ssl> and specify the password in cleartext.
>> Any suggestions?
>
> In NSS case, key passwords = keystore passwords.
> So, we may like to have the configuration so that it will not make the
> domain.xml too complicated.
> Also, before adding this level of complexity, we may also need to
> think about how to get those passwords during server startup.
I completely agree. This is why I left any password configuration issues
from the original proposal and for future study. The outcome of this
will not affect the remaining attributes.
>>
>> > If that's the case, then can you elaborate the advantages of
>> > having various keystores? [Note that in order to configure
>> > it on the GlassFish server, you'll need to know the admin user
>> > and admin password].
>>
>> As I mentioned, the password restriction is temporary only. The added
>> benefit of being able to configure different trust domains for a single
>> appserver domain remains.
>>
>> > - Shouldn't the keystore/truststore types be enums (entities),
>> > rather than CDATA sections?
>>
>> Not sure. Any specified keystore-type will be passed as the argument to
>>
>> java.security.KeyStore.getInstance(<keystore-type>);
>
> In general, this is true. But, it may not be that simple in some cases.
Yes, I mentioned the JSSE case. Bottom line is that we need to keep
the list of keystore types extensible, meaning a CDATA type for this
attribute is probably more appropriate than an enum.
Thanks,
Jan
>>
>> Keystore impls are provider based, and providers may introduce their own
>> keystore types, meaning the list of supported keystore types is
>> extensible.
>>
>>
>> Jan
>>
>>>
>>>
>>> Jacob Hookom wrote:
>>>
>>>> In B2B WS world, this would be quite a nice enhancement.
>>>>
>>>> Jan Luehe wrote:
>>>>
>>>>> In GlassFish, all SSL-enabled HTTP (and IIOP) listeners share the
>>>>> same
>>>>> key- and truststore locations, which are specified via system
>>>>> properties.
>>>>> Also, the key- and truststore types are hard-coded to "JKS".
>>>>>
>>>>> Other containers such as Tomcat do not have this limitation.
>>>>>
>>>>> This limitation was also brought up in
>>>>>
>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=657
>>>>>
>>>>> The limitation in GlassFish can be fixed with a few minor code tweaks
>>>>> (at least in the HTTP, and possibly also in the IIOP case), but it
>>>>> will also require adding configuration support for key- and
>>>>> truststore
>>>>> locations and types at the HTTP and IIOP listener level.
>>>>>
>>>>> Therefore, I propose adding "keystore", "keystore-type",
>>>>> "truststore", and
>>>>> "truststore-type" attributes to the <ssl> element in domain.xml, as
>>>>> follows:
>>>>>
>>>>> Index: sun-domain_1_2.dtd
>>>>> ===================================================================
>>>>> RCS file:
>>>>> /cvs/glassfish/admin-core/config-api/dtds/sun-domain_1_2.dtd,v
>>>>> retrieving revision 1.20
>>>>> diff -u -r1.20 sun-domain_1_2.dtd
>>>>> --- sun-domain_1_2.dtd 21 Mar 2006 03:04:39 -0000 1.20
>>>>> +++ sun-domain_1_2.dtd 8 Jun 2006 16:30:12 -0000
>>>>> @@ -949,7 +949,11 @@
>>>>> ssl3-tls-ciphers CDATA #IMPLIED
>>>>> tls-enabled %boolean; "true"
>>>>> tls-rollback-enabled %boolean; "true"
>>>>> - client-auth-enabled %boolean; "false">
>>>>> + client-auth-enabled %boolean; "false"
>>>>> + keystore CDATA #IMPLIED
>>>>> + keystore-type CDATA #IMPLIED
>>>>> + truststore CDATA #IMPLIED
>>>>> + truststore-type CDATA #IMPLIED>
>>>>>
>>>>> The keystore and truststore locations can be either absolute paths or
>>>>> will be interpreted relative to ${com.sun.aas.instanceRoot}.
>>>>>
>>>>> (In a future refinement, we could also add support for individual
>>>>> keystore and truststore passwords.)
>>>>>
>>>>> Please let me know what you think.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jan
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>