You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Alex A <al...@alex-andr.org> on 2010/11/24 22:34:43 UTC
Is this list completely dead?
I wonder if anyone ever responds to any user's questions posted to this
list?
Cheers,
~ Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Is this list completely dead?
Posted by Andreas Veithen <an...@gmail.com>.
Yes.
On Wed, Nov 24, 2010 at 22:34, Alex A <al...@alex-andr.org> wrote:
> I wonder if anyone ever responds to any user's questions posted to this
> list?
>
> Cheers,
> ~ Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
AW: Is this list completely dead?
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
Alex
Just reading your last e-mail,
First - I can perhaps not give you an answer for all your questions,
things you need to tell us are not yet said in this last e-mail.
Second - So I would like to know more about your own client and server
platform environment, what are you intending to use to make it happen?
I guess - it is an extension to the IIS server, isn't it? Or is it a
axis2 server running on apache-tomcat on your MS machine? What role
plays IIS then?
Third - we have long lasting sessions implemented between MS WFC 3.5
client talking to a Apache Axis2-1.2 Server running in
scope="soapsession" mode.
And it works perfect. BUT - No - in case of IIS running as
web-service-engine, I don't know how that shall work, unless IIS
forwards web-service-request to an Axis2-Webservice.
Does it do that? What is the intention here.
So I can talk only for an Axis2-Webservice with long-lasting sessions,
and if IIS is more of the party you might have to transfer part of your
questions to Microsoft.
But think: in general - your platform independence comes by protocol.
Jave-Client to MS-IIS-Server is one issue, and MS WCF 3.2 or ASP.NET
client to Axis2/Java would be another challenge.
Approach: best make client and server first work in each environment,
trimmed to long-lasting-sessions and authentication. Then sample and
study the protocol use by tcp monitor; If you cannot make
long-lasting-sessions and authentication work in a clean MS world or a
clean Apache Axis2/Java world how can you estimate to make it work in a
heterogeneous MS-Apache world.
So as advise - do more simple things first and learn the unique things
of each environment, each world. Then study and compare the protocol
differences taken by tcp monitor.
Reading all your questions, I think it makes most senses to start with
long-lasting-sessions, this are sessions where each
session-request-thread ends at it's own service-proving-object!
Is that true for you as well? Is it what you want? If not - we can stop
here.
If you have established that, you can think how to authenticate the
requesting party further to avoid ongoing authentication needs within
each recurring request.
1. Soap sessions, authentication, authentication on a per request
from the same user-session -
Then you need long -lasting-sessions and hence you have to add
scope="soapsession" to your service.xml, add a init() and a (destroy()
method to your service-class,
2. WS-Addressing needs to be engaged on client and server side
3. Take tcp monitor and see that the first response returns a
servicegroupId in the Soap header
4. Return this servicegroupId in the soap header with each
consecutive request to the server,
that way, you will hit always the same instance of the
service-providing-object, identified by the servicegroupId
5. Do not forget to change the timeout value in the axis2.xml file
server side from 30000 ms to what you think is a proper timeout
within which at least a next request from your user-session-thread has
to come in to this instance of a service providing object,
Unless the destroy() method in your service-providing-object is called
by the axis2-engine, invalidating your axis2-web-service-object
(object meant as instance of your service providing class identified be
the servicegroupId)
So far for long lasting sessions.
Scope="soapsession" guarantees that each user can have from its PC
several session-threads and that each session-thread talks always to the
same object (instance of a class) The object can then be a placeholder
for any beans connecting you further, such as HP WSIT beans to go to
OpenVMS Legacy Servers, calling JNI through the JVM into the C and C++
RTL's from Java etc etc.
As part of the very first call you need to do the authentication!
The question is now: who transfers the NTLM authentication credentials?
What are the NTLM pieces of information transmitted/exchanged? Do you
understand the NTLM protocol?
Also - NTLM authentication is a Microsoft proprietary authentication
protocol; hence it has a legal aspect!
Hence to find out how eligible it is to use it through Apache Axis2 you
need to contact Axis2 developers/management/legal-department.
But technically speaking: NTLM is a protocol which takes place in > 1
interaction between client and server.
Hence: where and who shall this pieces be transferred, who takes
ownership of this transfer?
So you may well establish first your service-providing-object and then
in a second stage start the NTLM authentication-sequence on the server
side.
This in absence of a better know-how from my side. Maybe somebody else
can better help you on that.
Considering a different but not NTLM authentication will bring you
closer to WS-Security* more suitable and open-source-like then anything
else;
and here is a lot to say, go for it in appropriate documentation,
presentations and standard documents;
Also in this regard, Microsoft helped a lot to "get it right for
Microsoft", helping defining the security-standards for WS-Security e
all.
Maybe there is some goodies in that as well.
We do long-lasting-sessions with a basic authentication, that is we pass
username and password today in clear text and will next change to a
DIGEST-Encrypted schema for the password. Knowing that DIGEST isn't real
secure.
Request:
1. On a firts request to login, axis2 engine creates an instance,
an object of the service-providing-class, a real object, and calls
init() on it, and then in turn calls login() on it which does the
authentication. In our case, login(OMelement e) gets called and receives
within the OMElement - username and password, this among other initial
things,
and then authentication is done by OpenVMS UAF
2. Request returns and if return args signals a failure through
exception, as i.e. password is not right, login is called a second and a
third time ...
3. If password is right user-methods are then called
4. And all is done by the same long lasting
service-providing-instance, a real object.
5. Also to know is that HTTP Headers must exact match
axis2-service expectations!
Make this example run first using java-axis2-client and
java-axis2-service running in scope="soapsession",
and monitor the HTTP header. If you later turn to a different client
implementation (as in our case) to MS VS WCF 3.5 client-stubs,
you need to add the servicegroupId SOAP Header and you need to add the
additional bits to the HTTP header in your
message-interception-technique to make axis2-engine think it is an
axis2-client calling in.
2) If I create several soap clients in one process, they all use the
same TCP connection.
Thus even if (1) gets resolved, mixing requests from different soap
sessions will break the authentication.
NO - If you manage to setup your client to web service with long lasting
sessions scope="soapsession"
then I guarantee you that one client process can make multiple
connections; Why?
Because - as long as each request transfers its own unique
servicegroupId in the header - as long each request will hit its own
unique service-providing object.
That is to say - dispatching a request to the service-providing-object
is then done slightly different than Axis2 schoolbooks for beginners
teach you. And it works real great!
The issue is how to make i.e. a MS WCF client sniffing in the extra
soap-header called servicegroupId.
(Answer: add a behavior object to your client and make it intercepting
message-requests and message-responses)
But if your client is Axis2-java, then this is done much more simple.
AND Again: where exactly the authentication of the request is done, is a
other bier.
And if somebody more know-ledged to the subject requested, I am eager to
learn!
BTW: we have to adopt WS-Security* e all over time into our established
long-lasting-session environment passing request-messages from WCF
Client to Axis2/J Services and many thing is absolute unclear to me
right now.
Joswef.Stadelmann
@axa-winterthur.ch
Von: Alex A [mailto:alex@alex-andr.org]
Gesendet: Donnerstag, 25. November 2010 13:19
An: java-user@axis.apache.org
Cc: Martin Gainty
Betreff: Re: Is this list completely dead?
Ah, great, there is some life here :)
Here is my questions again,
if all questions can't be answered, it would be great to have at least
some answers or ideas.
Thanks!
- I need to have several simultaneous connections form one client to the
same SOAP service.
- Credentials, used in all connections are NOT the same - different
users and possibly even different authentication modes. But I would like
TCP connections to be preserved - especially for NTLM authentication so
it does not need to do 3-step auth every time.
- If all three (Basic, Digest, NTLM) enabled on the server side (IIS),
how can I force choosing particular type on the client side, per
connection? authenticator.setAuthSchemes() does not seem to work.
Also, can someone explain if
options.setProperty(WSClientConstants.CACHED_HTTP_STATE, new
HttpState());
is relevant, and what is the package name for WSClientConstants?
(this is taken from
http://axis.apache.org/axis2/java/core/docs/http-transport.html)
The behavior I see right now has the following problems (working with
Exchange server via EWS):
1) Even in case of just one soap session, with NTLM authentication,
every new request initially gets 401 and has to re-authenticate. Keeping
in mind that full request's xml is being sent over to server for
authentication, it's thrashing the performance.
With NTLM, TCP connection got to be authenticated, not request.
2) If I create several soap clients in one process, they all use the
same TCP connection. Thus even if (1) gets resolved, mixing requests
from different soap sessions will break the authentication.
3) I am unable to force-select the Authentication method I want (if all
available on the server).
Thanks,
~ Alex.
On 11/24/2010 7:44 PM, Martin Gainty wrote:
always..whats your question??
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.
Diese Nachricht dient lediglich dem Austausch von Informationen und
entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten
Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt
uebernehmen.
> Date: Wed, 24 Nov 2010 16:34:43 -0500
> From: alex@alex-andr.org
> To: java-user@axis.apache.org
> Subject: Is this list completely dead?
>
> I wonder if anyone ever responds to any user's questions posted to
this
> list?
>
> Cheers,
> ~ Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
Re: Is this list completely dead?
Posted by Alex A <al...@alex-andr.org>.
Ah, great, there is some life here :)
Here is my questions again,
if all questions can't be answered, it would be great to have at least
some answers or ideas.
Thanks!
> - I need to have several simultaneous connections form one client to
> the same SOAP service.
>
> - Credentials, used in all connections are NOT the same - different
> users and possibly even different authentication modes. But I would
> like TCP connections to be preserved - especially for NTLM
> authentication so it does not need to do 3-step auth every time.
>
> - If all three (Basic, Digest, NTLM) enabled on the server side (IIS),
> how can I force choosing particular type on the client side, per
> connection? authenticator.setAuthSchemes() does not seem to work.
>
> Also, can someone explain if
>
> options.setProperty(WSClientConstants.CACHED_HTTP_STATE, new
> HttpState());
>
> is relevant, and what is the package name for WSClientConstants?
> (this is taken from
> http://axis.apache.org/axis2/java/core/docs/http-transport.html)
The behavior I see right now has the following problems (working with
Exchange server via EWS):
1) Even in case of just one soap session, with NTLM authentication,
every new request initially gets 401 and has to re-authenticate. Keeping
in mind that full request's xml is being sent over to server for
authentication, it's thrashing the performance.
With NTLM, TCP connection got to be authenticated, not request.
2) If I create several soap clients in one process, they all use the
same TCP connection. Thus even if (1) gets resolved, mixing requests
from different soap sessions will break the authentication.
3) I am unable to force-select the Authentication method I want (if all
available on the server).
Thanks,
~ Alex.
On 11/24/2010 7:44 PM, Martin Gainty wrote:
> always..whats your question??
>
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.
> Diese Nachricht dient lediglich dem Austausch von Informationen und
> entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten
> Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den
> Inhalt uebernehmen.
>
>
>
>
>
> > Date: Wed, 24 Nov 2010 16:34:43 -0500
> > From: alex@alex-andr.org
> > To: java-user@axis.apache.org
> > Subject: Is this list completely dead?
> >
> > I wonder if anyone ever responds to any user's questions posted to this
> > list?
> >
> > Cheers,
> > ~ Alex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: java-user-help@axis.apache.org
> >
RE: Is this list completely dead?
Posted by Martin Gainty <mg...@hotmail.com>.
always..whats your question??
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Date: Wed, 24 Nov 2010 16:34:43 -0500
> From: alex@alex-andr.org
> To: java-user@axis.apache.org
> Subject: Is this list completely dead?
>
> I wonder if anyone ever responds to any user's questions posted to this
> list?
>
> Cheers,
> ~ Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>