Skip to main content

Re: Get a SAML token and print it in console - DotNet STS, Java Client

9 replies [Last post]
Anonymous

renatofsa wrote
>
> Could you send me the sample of code to connect in STS and get the token ?
>

Glen Mazza's tutorial is good one and he provides the sample code for
download. It will be more useful for you than what I have discussed in this
thread. I used his tutorial to learn the basics.

I attempted to get the token from STS manually and did it for experiment
sake. Generally this step will be done internally by metro runtime. Still if
you need it please let me know, I will share it.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
renatofsa

Joseph,

i've been confused because of the WCF i have the following steps:

1. Connect to the STS and get the token and cache-it;
2. On the request for de services (protected by the token) , i need to open
the channel and send the token;

as far as i understand on the metro i need to connect the protected service
and configure the endpoint of the STS and it gets the token and sends to the
service, correct ?

I have a question, in each request to the "security service", does a metro
call the STS and get the token ? or does it store it in any cache ?

I tried to use the netbeans "Web Service Client" to connect the security
service and configure the STS parameters, but i received the message error
below:

Thks a lot.

INFO: WSS0824: The certificate found in the server wsdl or by server cert
property is valid, so using it
INFO: WSP5018: Loaded WSIT configuration from file:
file:/C:/Users/Renato/Documents/NetBeansProjects/WebClient/build/web/WEB-INF/classes/META-INF/wsit-client.xml.
WARNING: SP0100: Policy assertion
Assertion[com.sun.xml.ws.security.impl.policy.SpnegoContextToken] {
assertion data {
namespace =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
prefix = 'sp'
local name = 'SpnegoContextToken'
value = 'null'
optional = 'false'
ignorable = 'false'
attributes {
name =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702:IncludeToken',
value =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient'
}
}
no parameters
nested policy {
namespace version = 'v1_5'
id = 'null'
name = 'null'
vocabulary {
1. entry =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702:MustNotSendAmend'
2. entry =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702:MustNotSendCancel'
3. entry =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702:MustNotSendRenew'
4. entry =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702:RequireDerivedKeys'
}
assertion set {

Assertion[com.sun.xml.ws.policy.sourcemodel.DefaultPolicyAssertionCreator$DefaultPolicyAssertion]
{
assertion data {
namespace =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
prefix = 'sp'
local name = 'MustNotSendAmend'
value = 'null'
optional = 'false'
ignorable = 'false'
no attributes
}
no parameters
no nested policy
}

Assertion[com.sun.xml.ws.policy.sourcemodel.DefaultPolicyAssertionCreator$DefaultPolicyAssertion]
{
assertion data {
namespace =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
prefix = 'sp'
local name = 'MustNotSendCancel'
value = 'null'
optional = 'false'
ignorable = 'false'
no attributes
}
no parameters
no nested policy
}

Assertion[com.sun.xml.ws.policy.sourcemodel.DefaultPolicyAssertionCreator$DefaultPolicyAssertion]
{
assertion data {
namespace =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
prefix = 'sp'
local name = 'MustNotSendRenew'
value = 'null'
optional = 'false'
ignorable = 'false'
no attributes
}
no parameters
no nested policy
}

Assertion[com.sun.xml.ws.policy.sourcemodel.DefaultPolicyAssertionCreator$DefaultPolicyAssertion]
{
assertion data {
namespace =
'http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
prefix = 'sp'
local name = 'RequireDerivedKeys'
value = 'null'
optional = 'false'
ignorable = 'false'
no attributes
}
no parameters
no nested policy
}
}
}
} is not supported under Token assertion.
SEVERE: SEC2004: Container-auth: wss: Error securing request
com.sun.xml.ws.client.ClientTransportException: The server sent HTTP status
code 404: Not Found
at
com.sun.xml.ws.transport.http.client.HttpTransportPipe.checkStatusCode(HttpTransportPipe.java:311)
at
com.sun.xml.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:260)
at
com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:218)
at
com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:137)
at
com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:138)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.client.Stub.process(Stub.java:323)
at
com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:192)
at
com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:218)
at
com.sun.xml.ws.security.trust.impl.TrustPluginImpl.invokeRST(TrustPluginImpl.java:628)
at
com.sun.xml.ws.security.trust.impl.TrustPluginImpl.process(TrustPluginImpl.java:174)
at
com.sun.xml.ws.security.trust.impl.client.STSIssuedTokenProviderImpl.getIssuedTokenContext(STSIssuedTokenProviderImpl.java:144)
at
com.sun.xml.ws.security.trust.impl.client.STSIssuedTokenProviderImpl.issue(STSIssuedTokenProviderImpl.java:74)
at
com.sun.xml.ws.api.security.trust.client.IssuedTokenManager.getIssuedToken(IssuedTokenManager.java:83)
at
com.sun.xml.wss.provider.wsit.WSITClientAuthContext.invokeTrustPlugin(WSITClientAuthContext.java:882)
at
com.sun.xml.wss.provider.wsit.WSITClientAuthContext.secureRequest(WSITClientAuthContext.java:323)
at
com.sun.xml.wss.provider.wsit.WSITClientAuthContext.secureRequest(WSITClientAuthContext.java:300)
at
com.sun.enterprise.security.webservices.ClientSecurityPipe.process(ClientSecurityPipe.java:162)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.client.Stub.process(Stub.java:323)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161)
at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:113)
at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144)
at $Proxy176.valor(Unknown Source)
at client.Client.valor(Client.java:96)
at client.Client.processRequest(Client.java:40)
at client.Client.doGet(Client.java:66)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)

Joseph

Hi Renatofsa,

Being a newbie in this area I also look forward to answers to the questions
you have posted, from experts around here.

>> SEVERE: SEC2004: Container-auth: wss: Error securing request

From the exception message, I suspect there might be issues with the
security certificates or its configuration.

How is the STS protected?

It would have been better, if you had started a new thread :-)

Regards,
Joseph.

tdanecito
Offline
Joined: 2005-10-10
Points: 0

Hi All,

I am seeing what looks like gets for the WSDL every time I make a JAXWS reuest. How can I turn this off? Seems like a terrible waste of bandwidth. I seem to remember someone else asking the same question years ago

Thanks,
-Tony

mcs130
Offline
Joined: 2006-01-26
Points: 0

I don't know if this helps but we use the practice of packaging the
WSDL/XSDs into a /META-INF/wsdl location of the resulting JAR file that
contains the generated client side artifacts (proxy and interface and types
to be exchanged). When this happens, the WSDL is read locally when the
object instance is created and no "wire call" to the WSDL occurs.

http://cxf.547215.n5.nabble.com/Generated-Service-proxy-client-side-CXF-...

The CXF JIRA entry created in this thread was already corrected and
distributed by the CXF team. You might be using JAX-WS RI/Metro and that
was what we were using when we started this practice of "localizing" the
WSDL/XSD in the JAR containing the artifacts from which they were
generated. We started looking at CXF which precipitated the thread above.

Hope this might help.

Mark

On Wed, Jun 13, 2012 at 11:03 AM, Tony Anecito wrote:

> Hi All,
>
> I am seeing what looks like gets for the WSDL every time I make a JAXWS
> reuest. How can I turn this off? Seems like a terrible waste of bandwidth.
> I seem to remember someone else asking the same question years ago
>
> Thanks,
> -Tony
>
>

tdanecito
Offline
Joined: 2005-10-10
Points: 0

HI Mark,
 
Thanks for the reply. I decided to take that approach but am running into issues. I am using wsgen and one of the options to inline the schemas seems to fail indicating wsgen2 does not support that option using ant and metro 2.2. I seem to understand getting the inline to work is critical since the xsd's you also want local to the jar.
 
Once I get past that issue then it is just the client side coding to point to the wsdl in the jar.
 
Are you using Ant with Metro libraries?
 
Thanks!
-Tony

tdanecito
Offline
Joined: 2005-10-10
Points: 0

Ok I figured out what is happening. With the metro I downloaded the attribute was removed because when you generate the wsdl it also creates the xsd and automatically puts both in the resultant war.
 
Now the next steps of putting the wsdl in a client side jar and setting up the code.
 
-Tony

mcs130
Offline
Joined: 2006-01-26
Points: 0

We were using JAX-WS RI 2.1.1 in JDK 6 at the time and it appears it was
"localizing" the referenced XSDs as well (it wrote them to the same
WEB-INF/wsdl of the web service WAR project and then we run a copy task
from Ant when building the web service client JAR where they get put into
/META-INF/wsdl).

Here is a snippet from the WSDL that got generated...

Note how the *schemaLocation *attributes point to the filename only , in
same location where the WSDL sits...not to some http:// URL with an xsd=1,
xsd=2, etc. And each namespace is respected as well... This seems to avoid
all the "in-line" mess.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

tdanecito
Offline
Joined: 2005-10-10
Points: 0

Thanks Mark! Yeah I just figured it out before I read this email. Now on to the client side code and packaging the files into a jar for the client.
 
Best Regards,
-tony

tdanecito
Offline
Joined: 2005-10-10
Points: 0

Ok got everything packaged and deployed and now only 1/2 the requests so seeing just POST in my logs for JAX-WS calls.
 
Again thanks for the help Mark.
 
-Tony