date:20120209

Re: Help: Element is referenced but not defined

2012-02-09 Thread Sagara Gunathunga

What is your Axis2 version ? Try to use Axis2 1.6.1 version I  didn't get
mentioned exception for given WSDL file using Axis2 1.6.1.

Thanks !

On Thu, Feb 9, 2012 at 11:52 AM, luckyjun85  wrote:

>
> Hi, I get this error when i try to run wsdl2java
>
>
> java.io.IOException: Element Service is referenced but not defined.
>at
>
> org.apache.axis.wsdl.symbolTable.SymbolTable.checkForUndefined(SymbolTable.java:670)
>at
> org.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:545)
>at
> org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:518)
>at
> org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:495)
>at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:361)
>
>
>
> Here is my WSDL
>
> 
> 
> http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:tns="http://www.tm.com.my/hsbb/eai/getCurrentBillStatement/";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:ns="http://schemas.xmlsoap.org/soap/encoding/";
> name="getCurrentBillStatement"
> targetNamespace="http://www.tm.com.my/hsbb/eai/getCurrentBillStatement/";>
>  
>
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>  
>
>  
>
>
>
>
>
>
>
>  
>
>  
>  
>
>  
>
>  
>
>  
>
>  
>  
>
>  
>  
>
>  
>  
>
>  
>  
>
>  
>   type="tns:getCurrentBillStatementPort">
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
>   soapAction="http://www.tm.com.my/hsbb/eai/getCurrentBillStatement"/>
>  
>
>  
>  
>
>  
>
>  
>  
> binding="tns:getCurrentBillStatementBinding">
>  http://localhost/getCurrentBillStatement/"/>
>
>  
> 
>
> *
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://old.nabble.com/Help%3A-Element-is-referenced-but-not-defined-tp33291168p33291168.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
> For additional commands, e-mail: java-user-h...@axis.apache.org
>
>


-- 
Sagara Gunathunga

Blog  - http://ssagara.blogspot.com
Web  - http://people.apache.org/~sagara/
LinkedIn - http://www.linkedin.com/in/ssagara

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

2012-02-09 Thread Amila Jayasekara

Hi Filippo,

IMO not many people use this kind of a communication pattern to
establish a security context. To my experience I haven't seen this is
implemented in other popular frameworks also (I maybe wrong). I think
for the same reason interoperability is also not clearly defined for
this kind of communication. But its great to have a such
implementation. I have some feedback on your suggestions when compared
with current Rampart implementation. (Please see inline comments)

On Wed, Feb 8, 2012 at 10:40 PM, FILIPPO AGAZZI
 wrote:
> Hi George and Prabath,
> thank you very much for your answers. I've read about CXF STS and OpenSSO,
> but until now i haven't found anything about supporting WS-Trust negotiation
> and challenge framework, although i'm not absolutely sure about this.
>
> Prabath, thanks, now i try to explain what i'm trying to do. As I said, i
> need a service that, when a client attempts to access, asks the client some
> type of authorization, and this is released through a negotiation process
> between client and service. This authorization can be obtained by the
> client, with the presentation of some credentials (service has, for example,
> a policy that requires the client possessing two credentials to have
> access). Also the client has some policy protecting his credentials, and ask
> the service to send it credentials in its turn, that the client asks in
> order to disclose the credentials asked by the service. This is the
> negotiation process i need, and i want to do this using WS-* standard: this
> is the reason why i thought about WS-trust negotation extension, that
> describe how client and service (probably the STS linked to the service) can
> exchange multiple (how much are needed) RequestSecurityTokenReponse
> messages,after the first RequestSecurityToken sent by the client.
>
> So i want to build a scenario where client and STS can exchange many
> RequestSecurityTokenResponse messages, where an important thing is that
> client and STS are completely unknown, and client hasn't got the STS policy.
> And here, the first question: in my experiments i figure out that STS needs
> some authentication and Cryptography in messages exchanged with the client
> (i refer to sample05 in Rampart distribution), and sts need to have
> client.jks: this doesn't match with my requirements, is it possible have an
> STS without any security policy mandatory for the messages (such as crypto
> or signature)?

Practically we need some mechanism to authenticate users against the
STS. Therefore we must have a security policy to authenticate users
against the STS. I just test whether it is possible to invoke STS
without a policy, but it seems it is not possible as per current
implementation.

I mean that STS release a security token to the client, that
> it uses to call the service, but the STS-policy, protecting the realising of
> the security token, is sent during the negotation.
>
> Then, now i add more details: the message exchange pattern i need is:
> client send a RequestSecurityToken message to the STS (and he doesn't know
> nothing about STS, so client doesn't add any security header in the
> message). STS answers with a RequestSecurityTokenReponse: this message have,
> as child of , xml custom elements,
> definded by a schema. These xml elements are structures that can contain
> some other custom xml child element (representing, for ex, negotation
> information, as negotiation strategies supported etc..), and also
>  element (policy that STS asks for relasing security token for
> the linked service). Client, in your turn, answers with another
> RequestSecurityTokenResponse, containing its negotiation information and its
> policy, within xml custom elements, contained by
> .
> After this 2 initials RequestSecurityTokenReponse messages, negotiation
> starts with some exchange of other RequestSecurityTokenReponse, that contain
> credentials both of the client and of the STS of the service the client
> wants to access. In this way i can have a negotiation process within
> WS-trust standard.
>
> I don't know if i could explain it in a good way, but summarizing i need
> client and STS custome exchanges of RequestSecurityTokenResponse containing
> arbitrary XML structures. I see in ws-trust 1.4, the 
> element, that i thought can be used to contain my custom element. I need
> also that client and STS (or service) communicate each other with their own
> trust negotiation framework, before answering to the other part.
> As a solution, i thought to implemente a client-handler and a STS-handler,
> in order to have as many messages as i want between client and STS, and in
> the hanlders building my soap custom message..but i have no idea how to make
> the handlers communicating each other, without let the messages hitting
> client and STS..i mean that these handlers need to be the first who handle
> the incominig messages, in order to have the scenario i described.Do u think
> is it a possibile solution?

Ab

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

2012-02-09 Thread FILIPPO AGAZZI

Hi Amila,
thanks for your response. So you suggest to use
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, instead of
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue?
I've already think about this, but i don't understand what are the
advantages that i get using SCT action, rather than Issue action, if you
could explain me, i really appreciate.


2012/2/9 Amila Jayasekara 


> Above could be a possible solution. But let me briefly describe how
> existing Rampart handles, this. In the current Rampart engine we have
> a specific client called “STSClient” [2]. STSClient is responsible for
> creating “RequestSecurityToken” with appropriate data. “STSClient”
> also sets an special action
> (http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT). If there is a
> security policy attached to STS client it will process approprate
> security and send. Once server side receives the message it will first
> process the security headers coming with “RequestSecurityToken”. (I
> guess in your case you have to modify this code to work without
> security headers for  “ RequestSecurityToken”).


This is a useful suggestion, but i'm not sure of which part of code i have
to modfy. Do you mean i have to modify rampart handler, to make it work
without security header? If i can do this, it could be a good way. And
then, modifying STSMessageReceiver, i could be able to establish an
exchange of RequestSecurityTokenReponse between STSClient and
STSMessageReceiver, are you suggesting this way? Another doubt: with this
scenario, i don't have to implement any Issuer?

Thank you very much!
Filippo A.



> Once security headers
> are processed, message will be routed to “STSMessageReceiver” [1]
> (Rampart identifies that message should be routed to
> STSMessageReceiver by looking at the action). “STSMessageReceiver” is
> responsible for processing “ RequestSecurityToken” and creating
> “RequestSecurityTokenResponse”. As per now we have a single round. But
> in your case you need to have several rounds of message exchanges
> before you negotiate a secret (establing a context).
> In summary, within Rampart we are handling communication with STS
> using a client and a message receiver. As per my understanding you
> should also be able to extend the current “ STSMessageReceiver”
> implementation and implement your logic.
>
>
>
> >
> > Any idea, suggestions is very very appreciated! Sorry for the lenght of
> this
> > message!!!
> > Thank a lot in advance,
> >
> > Best regards
> >
> > Filippo Agazzi
> >
> >
> > 2012/2/8 Prabath Siriwardena 
> >>
> >> Hi George,
> >>
> >> Sure.. you are somewhat out dated :-)
> >>
> >> The rampart STS has support for WS-Trust 1.3 as well as some parts of
> the
> >> WS-Trust 1.4  and we ship this with WSO2 Identity Server product - and
> the
> >> STS been used in real production scenarios..
> >>
> >> Hi Flippo,
> >>
> >> Yes, as you mentioned your requirement is not supported yet.. But we can
> >> help you building it.. Please provide further insights in to the
> >> requirement...
> >>
> >> Thanks & regards,
> >> -Prabath
> >>
> >> On Wed, Feb 8, 2012 at 8:29 AM, George Stanchev 
> >> wrote:
> >>>
> >>> Hi Filippo,
> >>>
> >>>
> >>>
> >>> I don’t believe the Axis2 STS is mature enough to support what you are
> >>> asking about. Neither rampart contains a general-purpose WS-Trust
> client.
> >>> AFAIK the main purpose of the Axis2 STS is to server SCTs for
> >>> WS-SecureConversation. Granted, I’ve stopped following its development
> for a
> >>> while so others might correct me if I am wrong.
> >>>
> >>>
> >>>
> >>> I am not sure anything you ask for is available as open source. You can
> >>> try checking out the Apache CFX STS implementation which was donated by
> >>> Talend which could be more mature. CXF also might have a more mature
> client.
> >>> Other than that, you can also check Sun’s OpenSSO or any other more
> >>> comprehensive SSO implementation. [1] contains some starting point
> links.
> >>>
> >>>
> >>>
> >>> George
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> [1] http://kantarainitiative.org/wordpress/programs/iop-saml/
> >>>
> >>>
> >>>
> >>> From: FILIPPO AGAZZI [mailto:filippo.aga...@studenti.unipr.it]
> >>> Sent: Tuesday, February 07, 2012 7:28 AM
> >>> To: java-user@axis.apache.org
> >>> Subject: [Axis2] [Rampart] ws-trust negotiation and challenge extension
> >>> support
> >>>
> >>>
> >>>
> >>> Hi all,
> >>> i'm Filippo Agazzi, an Informatic Engineer student at University of
> >>> Parma, Italy. i'm working on a thesis about "Automated trust
> negotiation
> >>> using ws-* standard", and i need, as a basis, to have a client and a
> service
> >>> (probably a STS), challenging each other and exchanging multiple
> >>> RequestSecurityTokenReponse message, before a final message is sent by
> the
> >>> service to the client. I see that ws-Trust includes a negotation and
> >>> challenge framework; so my question is: is there any support or
> >>> imple

[Axis2] [Rampart] two questions

2012-02-09 Thread James Annesley

Hi,

 

Two questions:

 

Introduction:

 

I use Rampart 1.5.0 and Axis2 1.5.1. The SOAP server is WCF and it works ok.
The policy is embedded in the SOAP and the AXIS2 client works after engaging
Rampart without specifying a policy file.

The authentication is done on the SOAP server. For each client request the
username and password is inserted into the ServiceClient's Options object.
The strange thing is that Rampart also authenticates the username and
password. 

 

Question 1) Why does Rampart do its own authentication? I believe Rampart is
needed in order to interpret the WS-Security SOAP messages - but I don't
need it to do anything else.

 

Question 2) Really what I would like to do is leverage Tomcat's login
features and still authenticate via the current system. I don't want to have
to import all the authenticated users to the tomcat database and would
prefer not having to implement something new on the SOAP server. I realise
this might be more appropriate for the tomcat list. Any ideas?

 

Cheers,

 

James


Infoshare Ltd
Millennium House
21 Eden Street
Kingston upon Thames
Surrey
KT1 1BL
United Kingdom

Phone:  + 44 (0) 20 8541 0111
Support:+ 44 (0) 20 8481 4760
Web:www.infoshare-is.com
E-mail: i...@infoshare-is.com

Infoshare Ltd is registered in England and Wales.
Registered Office as above.
Registered Number 2877612
VAT Number GB 678 1443 10

The content of this e-mail (and any attachment to it) is confidential. 
Any views or opinions do not represent the views or opinions 
of Infoshare Ltd.
If you have received this e-mail in error please notify the sender 
and delete it. You may not use, copy or disclose the information 
in any way. 

Infoshare Ltd monitors incoming and outgoing e-mails.

Please consider the environment. Do you really need to print 
this email?

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

2012-02-09 Thread Sardar Hussain

How WS-SecureConversation fits in here. Similar type of tokens are supposed to 
be exchanged.

I think Ramprt supports ws-SecureConversation.

 From: FILIPPO AGAZZI 
To: java-user@axis.apache.org 
Sent: Thursday, 9 February 2012, 12:03
Subject: Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension 
support

Hi Amila,
thanks for your response. So you suggest to use 
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, instead of 
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue ? I've already think 
about this, but i don't understand what are the advantages that i get using SCT 
action, rather than Issue action, if you could explain me, i really 
appreciate.  

2012/2/9 Amila Jayasekara 

>Above could be a possible solution. But let me briefly describe how
>existing Rampart handles, this. In the current Rampart engine we have
>a specific client called “STSClient” [2]. STSClient is responsible for
>creating “RequestSecurityToken” with appropriate data. “STSClient”
>also sets an special action
>(http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT). If there is a
>security policy attached to STS client it will process approprate
>security and send. Once server side receives the message it will first
>process the security headers coming with “RequestSecurityToken”. (I
>guess in your case you have to modify this code to work without
>security headers for  “ RequestSecurityToken”).

This is a useful suggestion, but i'm not sure of which part of code i have to 
modfy. Do you mean i have to modify rampart handler, to make it work without 
security header? If i can do this, it could be a good way. And then, modifying 
STSMessageReceiver, i could be able to establish an exchange of 
RequestSecurityTokenReponse between STSClient and STSMessageReceiver, are you 
suggesting this way? Another doubt: with this scenario, i don't have to 
implement any Issuer?

Thank you very much! 
Filippo A.

Once security headers
>are processed, message will be routed to “STSMessageReceiver” [1]
>(Rampart identifies that message should be routed to
>STSMessageReceiver by looking at the action). “STSMessageReceiver” is
>responsible for processing “ RequestSecurityToken” and creating
>“RequestSecurityTokenResponse”. As per now we have a single round. But
>in your case you need to have several rounds of message exchanges
>before you negotiate a secret (establing a context).
>In summary, within Rampart we are handling communication with STS
>using a client and a message receiver. As per my understanding you
>should also be able to extend the current “ STSMessageReceiver”
>implementation and implement your logic.
>
>
>
>
>>
>> Any idea, suggestions is very very appreciated! Sorry for the lenght of this
>> message!!!
>> Thank a lot in advance,
>>
>> Best regards
>>
>> Filippo Agazzi
>>
>>
>> 2012/2/8 Prabath Siriwardena 
>>>
>>> Hi George,
>>>
>>> Sure.. you are somewhat out dated :-)
>>>
>>> The rampart STS has support for WS-Trust 1.3 as well as some parts of the
>>> WS-Trust 1.4  and we ship this with WSO2 Identity Server product - and the
>>> STS been used in real production scenarios..
>>>
>>> Hi Flippo,
>>>
>>> Yes, as you mentioned your requirement is not supported yet.. But we can
>>> help you building it.. Please provide further insights in to the
>>> requirement...
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>> On Wed, Feb 8, 2012 at 8:29 AM, George Stanchev 
>>> wrote:

 Hi Filippo,

 I don’t believe the Axis2 STS is mature enough to support what you are
 asking about. Neither rampart contains a general-purpose WS-Trust client.
 AFAIK the main purpose of the Axis2 STS is to server SCTs for
 WS-SecureConversation. Granted, I’ve stopped following its development for 
 a
 while so others might correct me if I am wrong.

 I am not sure anything you ask for is available as open source. You can
 try checking out the Apache CFX STS implementation which was donated by
 Talend which could be more mature. CXF also might have a more mature 
 client.
 Other than that, you can also check Sun’s OpenSSO or any other more
 comprehensive SSO implementation. [1] contains some starting point links.

 George

 [1] http://kantarainitiative.org/wordpress/programs/iop-saml/

 From: FILIPPO AGAZZI [mailto:filippo.aga...@studenti.unipr.it]
 Sent: Tuesday, February 07, 2012 7:28 AM
 To: java-user@axis.apache.org
 Subject: [Axis2] [Rampart] ws-trust negotiation and challenge extension
 support

 Hi all,
 i'm Filippo Agazzi, an Informatic Engineer student at University of
 Parma, Italy. i'm working on a thesis about "Automated trust negotiation
 using ws-* standard", and i need, as a basis, to have a client and a 
 service
 (probably a STS), challenging each other and exchanging multiple
 Reque

Axis2 wsdl2java - cannot be resolved error using choice in extension base for a complexcontent

2012-02-09 Thread Krishna Kerekatte


Hi,

I get a compile error, "cannot be resolved" for code generated with Axis2
wsdl2java when the schema has an extension base with a choice. Here's the
example:













When the code is generated for ArrangementCmDetailType it generates boolean
variables for each element in the "choice" as well as references to boolean
variables in the parent class, ArrangementType, for each of its element. The
variables are suffixed with Tracker. However, the class ArrangementType does
not have the Tracker variables defined. 













I noticed that the ArrangementType only had the Tracker variables for the
optional elements (minOccurs="0"), i.e. ArEndDte and ArEltrnAccElgblInd. 

I am getting the unresolved variables error in ArrangementCmDetailType for
all the other elements: localArKeyTracker, localArTypTracker,
localArProdDefTracker, localArStatTracker and localArStrtDteTracker. 


I am using Axis2-1.4.1 but also found the issue with wsdl2java in
Axis2-1.6.1. 
Any help is appreciated.

Thanks,
Krishna



-- 
View this message in context: 
http://old.nabble.com/Axis2-wsdl2java---cannot-be-resolved-error-using-choice-in-extension-base-for-a-complexcontent-tp33294695p33294695.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

2012-02-09 Thread Ruchith Fernando

Hi,

On Thu, Feb 9, 2012 at 5:22 AM, Amila Jayasekara  wrote:
> Hi Filippo,
>
> IMO not many people use this kind of a communication pattern to
> establish a security context. To my experience I haven't seen this is
> implemented in other popular frameworks also (I maybe wrong). I think
> for the same reason interoperability is also not clearly defined for
> this kind of communication. But its great to have a such
> implementation. I have some feedback on your suggestions when compared
> with current Rampart implementation. (Please see inline comments)
>
> On Wed, Feb 8, 2012 at 10:40 PM, FILIPPO AGAZZI
>  wrote:
>> Hi George and Prabath,
>> thank you very much for your answers. I've read about CXF STS and OpenSSO,
>> but until now i haven't found anything about supporting WS-Trust negotiation
>> and challenge framework, although i'm not absolutely sure about this.
>>
>> Prabath, thanks, now i try to explain what i'm trying to do. As I said, i
>> need a service that, when a client attempts to access, asks the client some
>> type of authorization, and this is released through a negotiation process
>> between client and service. This authorization can be obtained by the
>> client, with the presentation of some credentials (service has, for example,
>> a policy that requires the client possessing two credentials to have
>> access). Also the client has some policy protecting his credentials, and ask
>> the service to send it credentials in its turn, that the client asks in
>> order to disclose the credentials asked by the service. This is the
>> negotiation process i need, and i want to do this using WS-* standard: this
>> is the reason why i thought about WS-trust negotation extension, that
>> describe how client and service (probably the STS linked to the service) can
>> exchange multiple (how much are needed) RequestSecurityTokenReponse
>> messages,after the first RequestSecurityToken sent by the client.
>>
>> So i want to build a scenario where client and STS can exchange many
>> RequestSecurityTokenResponse messages, where an important thing is that
>> client and STS are completely unknown, and client hasn't got the STS policy.
>> And here, the first question: in my experiments i figure out that STS needs
>> some authentication and Cryptography in messages exchanged with the client
>> (i refer to sample05 in Rampart distribution), and sts need to have
>> client.jks: this doesn't match with my requirements, is it possible have an
>> STS without any security policy mandatory for the messages (such as crypto
>> or signature)?
>
> Practically we need some mechanism to authenticate users against the
> STS. Therefore we must have a security policy to authenticate users
> against the STS. I just test whether it is possible to invoke STS
> without a policy, but it seems it is not possible as per current
> implementation.
>
> I mean that STS release a security token to the client, that
>> it uses to call the service, but the STS-policy, protecting the realising of
>> the security token, is sent during the negotation.

Are you trying to obtain the STS policy + certificate information
using an RST/RSTR interaction with the STS?

Isn't the proper WS-* way of negotiating the access policy is using
WS-MetadataExchange?
I believe Axis2 has support for this and it interops with WCF.
Furthermore, I guess you should be able to add custom policy elements
to the WS-SecurityPolicy to include certification information.

>>
>> Then, now i add more details: the message exchange pattern i need is:
>> client send a RequestSecurityToken message to the STS (and he doesn't know
>> nothing about STS, so client doesn't add any security header in the
>> message). STS answers with a RequestSecurityTokenReponse: this message have,
>> as child of , xml custom elements,
>> definded by a schema. These xml elements are structures that can contain
>> some other custom xml child element (representing, for ex, negotation
>> information, as negotiation strategies supported etc..), and also
>>  element (policy that STS asks for relasing security token for
>> the linked service). Client, in your turn, answers with another
>> RequestSecurityTokenResponse, containing its negotiation information and its
>> policy, within xml custom elements, contained by
>> .
>> After this 2 initials RequestSecurityTokenReponse messages, negotiation
>> starts with some exchange of other RequestSecurityTokenReponse, that contain
>> credentials both of the client and of the STS of the service the client
>> wants to access. In this way i can have a negotiation process within
>> WS-trust standard.
>>
>> I don't know if i could explain it in a good way, but summarizing i need
>> client and STS custome exchanges of RequestSecurityTokenResponse containing
>> arbitrary XML structures. I see in ws-trust 1.4, the 
>> element, that i thought can be used to contain my custom element. I need
>> also that client and STS (or service) communicate each other with their own
>> trust ne

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

2012-02-09 Thread Ruchith Fernando

On Thu, Feb 9, 2012 at 7:03 AM, FILIPPO AGAZZI
 wrote:
> Hi Amila,
> thanks for your response. So you suggest to use
> http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, instead of
> http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue ? I've already think
> about this, but i don't understand what are the advantages that i get using
> SCT action, rather than Issue action, if you could explain me, i really
> appreciate.

Using http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT would route
your request to the security context token issuer that is included in
the rampart STS implementation. I believe you will have to use
"http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue"; and use a
custom token type.

This leads to coding your own token issuer which should maintain some
state with respect to the stage in the negotiation the issuer is in
with respect to a particular client.

>
>
> 2012/2/9 Amila Jayasekara 
>
>>
>> Above could be a possible solution. But let me briefly describe how
>> existing Rampart handles, this. In the current Rampart engine we have
>> a specific client called “STSClient” [2]. STSClient is responsible for
>> creating “RequestSecurityToken” with appropriate data. “STSClient”
>> also sets an special action
>> (http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT). If there is a
>> security policy attached to STS client it will process approprate
>> security and send. Once server side receives the message it will first
>> process the security headers coming with “RequestSecurityToken”. (I
>> guess in your case you have to modify this code to work without
>> security headers for  “ RequestSecurityToken”).
>
>
> This is a useful suggestion, but i'm not sure of which part of code i have
> to modfy. Do you mean i have to modify rampart handler, to make it work
> without security header? If i can do this, it could be a good way. And then,
> modifying STSMessageReceiver, i could be able to establish an exchange of
> RequestSecurityTokenReponse between STSClient and STSMessageReceiver, are
> you suggesting this way? Another doubt: with this scenario, i don't have to
> implement any Issuer?

What if you don't engage rampart when engaging rahas to setup the STS?
In that case it won't require the presence of a security header. If
this is the case it should simply let the RST through to the
STSMessageReceiver where it will look at the request type and token
type to pick the appropriate issuer (a custom issuer in this case).
This way you will only have to write your own issuer. I'll verify
whether this is possible if I can find some time.

Thanks,
Ruchith

-
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org

Re: Help: Element is referenced but not defined

2012-02-09 Thread Andreas Veithen

There are two things here:

1. The WSDL is not WS-I compliant because it violates the following requirement:

R2105 All xsd:schema elements contained in a wsdl:types element of a
DESCRIPTION MUST have a targetNamespace attribute with a valid and
non-null value, UNLESS the xsd:schema element has xsd:import and/or
xsd:annotation as its only child element(s). [BP2107]

2. To determine the namespace of an element or type definition in a
schema, wsdl2java naively walks up the node hierarchy until it finds
an element with a targetNamespace attribute. Since your schema doesn't
have a targetNamespace attribute, it would take the value from the
targetNamespace attribute of the wsdl:definitions element. This
results in the "Element ... is referenced but not defined" error
message. You can work around this issue by adding targetNamespace=""
to the xsd:schema element (provided that you don't want to or can't
make the WSDL WS-I compliant).

Andreas

On Thu, Feb 9, 2012 at 07:22, luckyjun85  wrote:
>
> Hi, I get this error when i try to run wsdl2java
>
>
> java.io.IOException: Element Service is referenced but not defined.
>        at
> org.apache.axis.wsdl.symbolTable.SymbolTable.checkForUndefined(SymbolTable.java:670)
>        at
> org.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:545)
>        at
> org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:518)
>        at
> org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:495)
>        at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:361)
>
>
>
> Here is my WSDL
>
> 
> 
> http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:tns="http://www.tm.com.my/hsbb/eai/getCurrentBillStatement/";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:ns="http://schemas.xmlsoap.org/soap/encoding/";
> name="getCurrentBillStatement"
> targetNamespace="http://www.tm.com.my/hsbb/eai/getCurrentBillStatement/";>
>  
>    
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>            
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>      
>        
>          
>            
>            
>            
>            
>            
>            
>            
>          
>        
>      
>      
>        
>          
>            
>          
>        
>      
>    
>  
>  
>    
>  
>  
>    
>  
>  
>    
>      
>      
>    
>  
>   type="tns:getCurrentBillStatementPort">
>     transport="http://schemas.xmlsoap.org/soap/http"/>
>    
>       soapAction="http://www.tm.com.my/hsbb/eai/getCurrentBillStatement"/>
>      
>        
>      
>      
>        
>      
>    
>  
>  
>     binding="tns:getCurrentBillStatementBinding">
>      http://localhost/getCurrentBillStatement/"/>
>    
>  
> 
>
> *
>
>
>
>
>
>
>
>
> --
> View this message in context: 
> http://old.nabble.com/Help%3A-Element-is-referenced-but-not-defined-tp33291168p33291168.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
> For additional commands, e-mail: java-user-h...@axis.apache.org
>

-
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

2012-02-09 Thread Ruchith Fernando

Hi Filippo,

On Thu, Feb 9, 2012 at 3:51 PM, Ruchith Fernando
 wrote:
> On Thu, Feb 9, 2012 at 7:03 AM, FILIPPO AGAZZI
>  wrote:
>> Hi Amila,
>> thanks for your response. So you suggest to use
>> http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, instead of
>> http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue ? I've already think
>> about this, but i don't understand what are the advantages that i get using
>> SCT action, rather than Issue action, if you could explain me, i really
>> appreciate.
>
> Using http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT would route
> your request to the security context token issuer that is included in
> the rampart STS implementation. I believe you will have to use
> "http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue"; and use a
> custom token type.
>
> This leads to coding your own token issuer which should maintain some
> state with respect to the stage in the negotiation the issuer is in
> with respect to a particular client.
>
>>
>>
>> 2012/2/9 Amila Jayasekara 
>>
>>>
>>> Above could be a possible solution. But let me briefly describe how
>>> existing Rampart handles, this. In the current Rampart engine we have
>>> a specific client called “STSClient” [2]. STSClient is responsible for
>>> creating “RequestSecurityToken” with appropriate data. “STSClient”
>>> also sets an special action
>>> (http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT). If there is a
>>> security policy attached to STS client it will process approprate
>>> security and send. Once server side receives the message it will first
>>> process the security headers coming with “RequestSecurityToken”. (I
>>> guess in your case you have to modify this code to work without
>>> security headers for  “ RequestSecurityToken”).
>>
>>
>> This is a useful suggestion, but i'm not sure of which part of code i have
>> to modfy. Do you mean i have to modify rampart handler, to make it work
>> without security header? If i can do this, it could be a good way. And then,
>> modifying STSMessageReceiver, i could be able to establish an exchange of
>> RequestSecurityTokenReponse between STSClient and STSMessageReceiver, are
>> you suggesting this way? Another doubt: with this scenario, i don't have to
>> implement any Issuer?
>
> What if you don't engage rampart when engaging rahas to setup the STS?
> In that case it won't require the presence of a security header. If
> this is the case it should simply let the RST through to the
> STSMessageReceiver where it will look at the request type and token
> type to pick the appropriate issuer (a custom issuer in this case).
> This way you will only have to write your own issuer. I'll verify
> whether this is possible if I can find some time.
>

I just hacked up a small STS to test my claim of invoking the STS
without engaging ranpart(i.e. without the requirement of a security
header) . Rahas currently requires the presence of security headers
(org.apache.rahas.RahasData#processWSS4JSecurityResults()). I made
this requirement optional in my code and then I was able to
successfully deploy a custom token issuer. I was able to communicate
with this token issuer using a custom client without using STSClient.

I will post a link to the code.

Thanks,
Ruchith

-
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org

Re: [Axis2] [Rampart] two questions

2012-02-09 Thread Ruchith Fernando

Hi James,

On Thu, Feb 9, 2012 at 7:37 AM, James Annesley <
james.annes...@infoshare-is.com> wrote:

> Hi,
>
> ** **
>
> Two questions:
>
> ** **
>
> Introduction:
>
> ** **
>
> I use Rampart 1.5.0 and Axis2 1.5.1. The SOAP server is WCF and it works
> ok. The policy is embedded in the SOAP and the AXIS2 client works after
> engaging Rampart without specifying a policy file.
>
> The authentication is done on the SOAP server. For each client request the
> username and password is inserted into the ServiceClient's Options object.
> The strange thing is that Rampart also authenticates the username and
> password. 
>
> ** **
>
> Question 1) Why does Rampart do its own authentication? I believe Rampart
> is needed in order to interpret the WS-Security SOAP messages - but I don't
> need it to do anything else.
>
 Rampart provides a callback mechanism which provides you the username and
password included in the incoming UsrnameToken for authentication (When you
use a plain text password). This callback handler which you implement as a
part of the service, carries out the authentication. For some reason if you
do not want to authenticate at this point but would rather authenticate at
the service implementation, that is still possible by obtaining the
security processing results from the message context of the incoming
request.


> **
>
> Question 2) Really what I would like to do is leverage Tomcat's login
> features and still authenticate via the current system. I don't want to
> have to import all the authenticated users to the tomcat database and would
> prefer not having to implement something new on the SOAP server. I realise
> this might be more appropriate for the tomcat list. Any ideas?
>

I'm not sure what you mean here.

Thanks,
Ruchith

Re: Help: Element is referenced but not defined

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

[Axis2] [Rampart] two questions

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

Axis2 wsdl2java - cannot be resolved error using choice in extension base for a complexcontent

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

Re: Help: Element is referenced but not defined

Re: [Axis2] [Rampart] ws-trust negotiation and challenge extension support

Re: [Axis2] [Rampart] two questions

11 matches

Site Navigation

Mail list logo

Footer information