there must be at most one config provider for a layer. This limitation
is unique to the domain.xml config system; which is tied to specific jsr
196 authconfigprovider.
It would also help if the layer argument (a string) could be unbounded
(but that is not necessary).
Ron
Anissa Lam wrote:
>
> Please see inline.
>
> Kumar Jayanti wrote:
>
>> Anissa Lam wrote:
>>
>>>
>>> I have some questions regarding <message-security-config>
>>>
>>> sun-domain_1_3.dtd specifies
>>>
>>> /<!ENTITY % message-layer "(SOAP | HttpServlet)">
>>> <!ELEMENT security-service
>>> (auth-realm+, jacc-provider+, audit-module*,
>>> message-security-config*, property*)>
>>> <!ATTLIST message-security-config
>>> auth-layer %message-layer; #REQUIRED
>>> default-provider CDATA #IMPLIED
>>> default-client-provider CDATA #IMPLIED>/
>>>
>>> Kumar mentioned user can create as many as they want.
>>
>> It maynot be as many as they want (i should have been more clear) but
>> there have to be atleast 2 one for message-layer SOAP and another one
>> for HttpServlet.
>
> If the above dtd is honored, although it may not make sense, but it
> is legal for user to create as many as they want.
>
>>> However, in CLI, there is no create-message-security-config
>>> command. (both v2 and v3)
>>
>> The command in V2 is :
>> Usage: create-message-security-provider [--terse=false] [--echo=false]
>> [--interactive=true] [--host localhost] [--port 4848|4849] [--secure |
>> -s] [--user admin_user] [--passwordfile file_name] [--target
>> target(Default server)] --classname provider_class [--layer
>> message_layer=SOAP] [--providertype provider_type]
>> [--requestauthsource request_auth_source] [--requestauthrecipient
>> request_auth_recipient] [--responseauthsource response_auth_source]
>> [--responseauthrecipient response_auth_recipient]
>> [--isdefaultprovider] [--property (name=value)[:name=value]*]
>> provider_name
>>
>> And you can see the message_layer argument there which is defaulted to
>> SOAP.
>
>
> create-message-security-provider is different than
> create-message-security-config. Are you saying that if
> message_layer argument is "httpServlet", then a message-security-config
> will be created with httpServlet as the message_layer ?
> And why is the syntax of this parameter is so different than the rest
> ? [--layer message_layer=SOAP] ? Does it imply different behavior ?
>
> thanks
> Anissa.
>
>>>
>>> In MessageSecurityConfig.java, it is declared as Singleton:
>>>
>>> @org.glassfish.api.amx.AMXConfigInfo(
>>> amxInterfaceName="com.sun.appserv.management.config.MessageSecurityConfig",
>>> singleton=true)
>>> @Configured
>>> public interface MessageSecurityConfig extends ConfigBeanProxy,
>>> Injectable
>>>
>>> So, how can we have a message-security-config with a
>>> message-layer of "HttpServlet" ?
>>>
>>
>> I guess this needs to be corrected
>
>>> Is <message-security-config> a singleton ?
>>>
>> No.
>>
>> regards,
>> kumar
>>
>>> If this is not singleton, then AMX needs to make changes.
>>> Currently, it is
>>> v3:pp=/domain/configs/config[server-config]/security-service,type=message-security-config
>>> without any unique identifier.
>>>
>>> Should GUI support the creation of additional
>>> message-security-config ? Can the security team let me know please ?
>>>
>>> thanks
>>> Anissa.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net> For additional
>>> commands, e-mail: dev-help_at_glassfish.dev.java.net
>>> <mailto: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