Hi all,

On Wed, Sep 7, 2011 at 12:46 AM, Thilina Buddhika <[email protected]> wrote:

>
>
> On Wed, Sep 7, 2011 at 12:43 AM, Thilina Buddhika <[email protected]>wrote:
>
>> Hi Senaka,
>>
>> I have to agree with Prabath. We already have a configuration similar to
>> the following in the authenticators.xml file inside conf/advanced.
>>
>> <Authenticators xmlns="http://wso2.org/projects/carbon/authenticators.xml
>> ">
>>
>>     <!-- Authenticator Configurations for TokenUIAuthenticator -->
>>     <Authenticator name="TokenUIAuthenticator" disabled="true">
>>         <Priority>5</Priority>
>>     </Authenticator>
>>
>>     .....
>>
>> </Authenticators>
>>
>> So having defined the same element Authenticator in the carbon.xml for a
>> different reason may confuse the user.
>>
>> AFAIK, this is used when some Carbon code is acting as a client to access
>> a remote resource. In the configurations you have shared, you are passing a
>> set of configurations to the authenticators, not the information about
>> authenticator itself. So how about using something like
>> ClientAuthenticationConfiguration instead of Authenticator ?
>>
>
> s/ClientAuthenticationConfiguration/AuthenticationConfiguration
>

Actually, this is used to construct an extension of java.net.Authenticator,
[1] for carbon. But, these are actually credentials, so may be we can use
the name you suggest. But, I have a better plan, how about adding the
following to authenticators.xml?

    <!-- Authenticator Configurations for java.net.Authenticator -->
    <Authenticator name="JavaNetworkAuthenticator">
        <Credential>
                <!--
                    the pattern that would match a subset of URLs for which
this credential
                    would be used
                -->
                <Pattern>.*</Pattern>
                <!--
                    the type of the network connection. Allowed values are:
                    1. server
                    2. proxy
                -->
                <Type>server</Type>
                <!-- the username used to log in to server/proxy -->
                <Username>name</Username>
                <!-- the password used to log in to server/proxy -->
                <Password>password</Password>
            </Credential>
            <Credential>
                <!--
                    the pattern that would match a subset of URLs for which
this credential
                    would be used
                -->
                <Pattern>.*</Pattern>
                <!--
                    the type of the network connection. Allowed values are:
                    1. server
                    2. proxy
                -->
                <Type>proxy</Type>
                <!-- the username used to log in to server/proxy -->
                <Username>name</Username>
                <!-- the password used to log in to server/proxy -->
                <Password>password</Password>
            </Credential>
    </Authenticator>

[1]
http://download.oracle.com/javase/1.5.0/docs/api/java/net/Authenticator.html

Thanks,
Senaka.

>
> Thanks,
> Thilina
>
>
>>
>> Thanks,
>> Thilina
>>
>> On Tue, Sep 6, 2011 at 11:58 AM, Senaka Fernando <[email protected]> wrote:
>>
>>> Hi Prabath,
>>>
>>> On Tue, Sep 6, 2011 at 7:56 AM, Prabath Siriwardena <[email protected]>wrote:
>>>
>>>> Hi Senaka,
>>>>
>>>> On Tue, Sep 6, 2011 at 1:47 AM, Senaka Fernando <[email protected]>
>>>> wrote:
>>>> > I've given this the name because this is standard Java terminology.
>>>> What we
>>>> > are implementing is an extension of java.net.Authenticator. Giving
>>>> this some
>>>> > other name would confuse somebody. Also having said that,
>>>> Authenticator in
>>>> > the java world is something that provides credentials for
>>>> authentication.
>>>> > But the CarbonAuthenticator IIRC is not doing quite that, making the
>>>> latter
>>>> > inconsistent. But, since we have been having it for a while, I'm not
>>>> sure
>>>> > what's the correct choice here. Anyway, giving this some other name
>>>> does not
>>>> > sound the correct thing to do.
>>>>
>>>> Even carbon authenticators take different type of credentials... and
>>>> this seems more like a proxy proxy configuration..
>>>>
>>>> This is the configuration [1] already used for axis2.
>>>>
>>>> <parameter name="PROXY"
>>>>    proxy_host="proxy_host_name"
>>>>    proxy_port="proxy_host_port"
>>>>    locked="true>userName:domain:passWord</parameter>
>>>>
>>>> >
>>>> > According to my understanding, with regard to proxy configuration in
>>>> Axis2,
>>>> > that's only if the server is fronted by a proxy while lies between
>>>> client
>>>> > and server (ex:- Apache2 mod_proxy). This fix is to allow the server
>>>> to
>>>> > access resources that lie behind multiple proxies (ex:- to access WSDL
>>>> > behind URL 1 you need proxy settings 1, and to access WSDL behind URL
>>>> 2 you
>>>> > need proxy settings 2). So, what you have in Axis2 is client-oriented
>>>> (i.e.
>>>> > for fixing WSDL URLs appropriately and all), and what we have
>>>> introduced in
>>>> > here is server-oriented.
>>>>
>>>> IIUC in your scenario Carbon server is trying to access a resource
>>>> behind a proxy and you need to authenticate to the proxy.. Shouldn't
>>>> this the same at the axis2 client end.. but this doesn't have multiple
>>>> proxy support as you mentioned. In either case shouldn't this
>>>> something to be in axis2.xml..? [not in carbon.xml]
>>>>
>>>
>>> This is not a transport-level thing that applies only to webservices.
>>> Axis2 is a webservices engine and this goes beyond that. For example, new
>>> URL("foo") call inside Java code, or accessing some resource through a web
>>> application is covered by this implementation. Also, this is not only for a
>>> proxy, but you can use it to access resources stored on a webserver that
>>> requires Basic, Digest, NTLM or SPNEGO authentication. If we introduce this
>>> into Axis2, it would be doing something additional (i.e. beyond its scope).
>>> What Axis2 has right now is sufficient for its use-cases, and this is
>>> something beyond that.
>>>
>>> Thanks,
>>> Senaka.
>>>
>>>
>>>> Thanks & regards,
>>>> -Prabath
>>>>
>>>> [1]: http://wso2.org/library/161
>>>> _______________________________________________
>>>> Carbon-dev mailing list
>>>> [email protected]
>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>
>>>
>>>
>>>
>>> --
>>> *Senaka Fernando*
>>> Product Manager - WSO2 Governance Registry;
>>> Associate Technical Lead; WSO2 Inc.; http://wso2.com*
>>> Member; Apache Software Foundation; http://apache.org
>>>
>>> E-mail: senaka AT wso2.com
>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>>> Linked-In: http://linkedin.com/in/senakafernando
>>>
>>> *Lean . Enterprise . Middleware
>>>
>>>
>>> _______________________________________________
>>> Carbon-dev mailing list
>>> [email protected]
>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>
>>>
>>
>>
>> --
>> Thilina Buddhika
>>
>> Associate Technical Lead
>> WSO2 Inc. ; http://wso2.com
>> lean . enterprise . middleware
>>
>> phone : +94 77 44 88 727
>> blog : http://blog.thilinamb.com
>>
>
>
>
> --
> Thilina Buddhika
> Associate Technical Lead
> WSO2 Inc. ; http://wso2.com
> lean . enterprise . middleware
>
> phone : +94 77 44 88 727
> blog : http://blog.thilinamb.com
>
> _______________________________________________
> Carbon-dev mailing list
> [email protected]
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>


-- 
*Senaka Fernando*
Product Manager - WSO2 Governance Registry;
Associate Technical Lead; WSO2 Inc.; http://wso2.com*
Member; Apache Software Foundation; http://apache.org

E-mail: senaka AT wso2.com
**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
Linked-In: http://linkedin.com/in/senakafernando

*Lean . Enterprise . Middleware
_______________________________________________
Carbon-dev mailing list
[email protected]
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Reply via email to