Skip to main content

SAML Tokens Interchange

27 replies [Last post]
ernestojpg
Offline
Joined: 2005-10-09

Hello everyone,

I want to know if this Use Case can be do at present with Metro:

The Client sends a Holder-of-key SAML Token with attributes, and the Web Service process the Token and respond to it with a new SAML Token with new attributes.

The Token that the client sends, because is a holder-of-key Token, contains the client public key, and it is signed by a Certifier Authority. The SAML Token that the Server issues is signed by he himself.

It's similar to a STS, but I want to do it with a simple Web Service.

Can this be do with wsit?

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ernestojpg
Offline
Joined: 2005-10-09

[i]> I believe the client is sending the SAML Assertion as
> a SupportingToken in your current scenario is that
> correct ?.
> [/i]

Are there any other form in which the client sends the SAML assertions to the STS?

Would I have to create custom STS so that the client sends the SAML assertions like parameters in a WebMethod call?

Ex:

[i]@WebService()
public class MyCustomSTS
{
@WebMethod
public String clientAuthenticate(String[] samlAssertions)
{
// Process attributes and return a new SAML Token with the authorization decision.
}
}[/i]

Is this the only form to send an uncertain number of SAML Assertions to the STS?

Thanks!

jdg6688
Offline
Joined: 2005-11-02

Hi,

If you don't have a customer STSAttributeProvider, then the default one is invoked for creating the SAML token. With this default STSAttributeProvider, we take what in the
Principal in the Subject (this Subject is created when the client token is authenticated)
as the SAML subject identity and then a dummy attribute. There is an issue here that
if the client authentication token is a SAML assertion, we don't put anything in the Principals in the Subject. That is the cause of your failure. We are fixing this issue.

In any case (also as a workaround for the above issue), you should supply a customer STSAttributeProvider to indicate the user identity and the user attribute (for example the role information of the user or any authorization code from your authorization decision as you indicated). For how to write and add the provider to the system, check this
blog entry:

http://blogs.sun.com/trustjdg/entry/create_customer_sts_with_wsit

Regards

jdg6688
Offline
Joined: 2005-11-02

> In any case (also as a workaround for the above
> issue), you should supply a customer
> STSAttributeProvider to indicate the user identity
> and the user attribute (for example the role
> information of the user or any authorization code
> from your authorization decision as you indicated).
Add "to be included in the issued SAML assertion".

ernestojpg
Offline
Joined: 2005-10-09

Hello everyone!

Are there any developments in this matter?

I still need to pass an undetermined number of SAML Tokens to the STS (or to a generic Web Service).

Can this be done in wsit now?

Thanks!

kumarjayanti
Offline
Joined: 2003-12-10

We have so far tried to fix issue :

https://wsit.dev.java.net/issues/show_bug.cgi?id=731

This would allow you to carry multiple SAML assertions inside a single assertion's Advice. Will that work for you ?.

We will also be fixing Issue https://wsit.dev.java.net/issues/show_bug.cgi?id=733, not sure if that would be of any help to you. You can then place each of those SAML assertions as SupportingTokens.

Other than that we are not planning any major change to support sending multiple SAML assertions in the immediate future.

If you have some suggestions please file an RFE.

Thanks.

ernestojpg
Offline
Joined: 2005-10-09

Thanks!

I think It could be a very interesting feature, because the client could have multiple Attribute Certificates, issued (and signed) by different Attribute Authorities.

I'm waiting for your news! :D

Regards.

ernestojpg
Offline
Joined: 2005-10-09

Hello,

Can anyone help me? Please kumarjayanti, jdg6688 ;)

I need to pass multiple SAML Tokens to the server. What you suggest to me?

Thanks!

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

We are internally discussing this and will get back to you on this later this week.

thanks.

ernestojpg
Offline
Joined: 2005-10-09

Thank you jdg6688.

But I need to do it, because It is very important to me. So, I will do it in no standard way. How could I do it?

I think in two possibilities:

1) To pass the SAML Assertions in the SOAP Header:

In this thread: http://forums.java.net/jive/thread.jspa?messageID=223369 is suggested the following:
On the client side, use a handler to put the SAML assertions in the SOAP header. On the server side, get the SAML assertion out using a handler and put it in the public credentails in the Subject.

2) To pass the SAML Assertions in the SOAP Body:

In an upper post, in this thread, I suggested to pass an Array of SAML Assertions in a parameter of the WebMethod. And on the Server side, verify the SAML signs (by hand), to make an access decision, and return a new SAML Token.

Which is the best solution in this case? What you suggest to me? ;)

Thanks!

ernestojpg
Offline
Joined: 2005-10-09

Are there any extension for STS that allows to send many (uncertain) Tokens to the STS?

If I use a handler (in the client) to put the SAML assertions in the SOAP header, are they validated by the STS and added to the PublicCredentials? Would I get they with Subject.getPublicCredentials() ?

Can somebody help me?

Thanks!

jdg6688
Offline
Joined: 2005-11-02

> Are there any extension for STS that allows to send
> many (uncertain) Tokens to the STS?

No standard way for doing this with WSIT for now. Although it is allowed in the latest WS-SecurityPolicy spec that more than one tokens can be used for a single Token Assertion. We need to investigate before saying if we can support this or not.
>
> If I use a handler (in the client) to put the SAML
> assertions in the SOAP header, are they validated by
> the STS and added to the PublicCredentials? Would I
> get they with Subject.getPublicCredentials() ?

No.

>
> Can somebody help me?
>
> Thanks!

ernestojpg
Offline
Joined: 2005-10-09

Hello!

> No standard way for doing this with WSIT for now.
> Although it is allowed in the latest
> WS-SecurityPolicy spec that more than one tokens can
> be used for a single Token Assertion. We need to
> investigate before saying if we can support this or
> not.

OK jdg6688, I will be waiting for the results of your investigation. ;)

I have been reading the WS-Trust specification (http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf), where is explained the 'Negotiation and Challenge Framework'. This framework extend the general mechanisms defined for requesting and returning security tokens, to support negotiations and challenges.

The exchange model is as follows:
1. A request is initiated with a that identifies the details of the request (and may contain initial negotiation/challenge information)
2. A response is returned with a that contains additional negotiation/challenge information. Optionally, this may return token information (if the exchange is two legs long).
3. If the exchange is not complete, the requestor uses a that contains additional negotiation/challenge information.
4. The process repeats at step 2 until the negotiation/challenge is complete (a token is returned or a Fault occurs).

The framework allows for an arbitrary number of exchanges. So, Could I use this mechanism to pass arbitrary number of SAML Tokens to the STS? Is this mechanism implemented in WSIT?

Thanks!

jdg6688
Offline
Joined: 2005-11-02

> I have been reading the WS-Trust specification
> (http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pd
> f), where is explained the 'Negotiation and Challenge
> Framework'. This framework extend the general
> mechanisms defined for requesting and returning
> security tokens, to support negotiations and
> challenges.
>
> The exchange model is as follows:
> 1. A request is initiated with a
> that identifies the
> details of the request (and may contain initial
> negotiation/challenge information)
> 2. A response is returned with a
> that contains
> additional negotiation/challenge information.
> Optionally, this may return token information (if the
> exchange is two legs long).
> 3. If the exchange is not complete, the requestor
> uses a that
> contains additional negotiation/challenge
> information.
> 4. The process repeats at step 2 until the
> negotiation/challenge is complete (a token is
> returned or a Fault occurs).
>
> The framework allows for an arbitrary number of
> exchanges.
This is just the general model. You need to develope your own Customer Exchange for your purpose.

> So, Could I use this mechanism to pass
> arbitrary number of SAML Tokens to the STS? Is this
> mechanism implemented in WSIT?

We don't support for mow.

>
> Thanks!

ernestojpg
Offline
Joined: 2005-10-09

Hi!

I have implemented a STSAttributeProvider in the STS and it work great! Now I can do a complete SAML Tokens interchange between Client, STS, and the Service Provider.

But I have a doubt. Could the client send many different SAML Tokens with attributes to the STS in the same RST petition? It is not obligatory, but it would be very good for me, because in my use case the client does not have only one SAML Token with attributes, but it has many SAML Tokens with attributes signed by different Certificate Authorities. The client couldn't to send all the attributes in the same SAML Token.

Could be this possible?

Thanks!

kumarjayanti
Offline
Joined: 2003-12-10

I believe the client is sending the SAML Assertion as a SupportingToken in your current scenario is that correct ?.

So if you want to send multiple of them you can add multiple SupportingToken assertions in your STS Policy and then the client should be able to send.

1. We have not tested this and so it may or maynot work, let us know if you run into some issue here and we will fix it.

2. If you are using the SAMLCallbackHandler mechanism on the client side to send a SAML Assertion then currently you cannot tell which SupportingToken a particular callback was made for (so long as this is Okay with you, things should work).

Thanks.

ernestojpg
Offline
Joined: 2005-10-09

Thanks kumarjayanti,

But there is a problem, I don't know how many SAML Tokens can have the client. Can be specified in the STS Policy that the client can send an uncertain number of SAML Tokens?

I suppose that no, because in the SAMLCallbackHandler mechanism, it is the STS Policy the one that specifies the number of Tokens which must be sent, am I right?

Is there some form to do this?

kumarjayanti
Offline
Joined: 2003-12-10

No, it is not possible to specify an uncertain number of such tokens. yes it is the STS policy in which this has to be specified.

Thanks.

ernestojpg
Offline
Joined: 2005-10-09

Hi !!

It is certain! I'm watching the Token that issues the STS:

- If the client is authenticated with “Sender Vouches” or “username”, then the STS issues a correct Token.

- If the client is authenticated with “Holder of Key”, then the STS issues a Token that does not contain the tag

[i]
......

[/i]

Now, I'm going to try to implement a STSAttributeProvider in the STS to indicate the user identity and the user attributes. Let you know if it worked.... ;)

Thank you very much jdg6688 and kumarjayanti !!

ernestojpg
Offline
Joined: 2005-10-09

Hi !

I will try to explain the example than I am doing. The system consists of 3 parts: A Service Provider (Web Service), a STS, and a Client.

1) The Client is authenticated by the STS with the holder-of-key mechanism (not 'username with Symmetric Keys' Authentication like in the WSIT tutorial). The client uses the SAMLCallbackHandler to construct the Holder-of-key Token and to pass some attributes.

2) The STS authenticate to the client and issue a new token with an authorization decision.

3) The Client accedes to the Service Provider passing the STS's Token to it.

This is the configuration for each one of the parts of the system. Everything is configured with NetBeans:

1) The STS:

- Security Mechanism: SAML Holder of Key
- KeyStore: Yes, alias: wssip
- Truststore: Yes
- Act As Secure Token Service (STS)

2) The Service Provider (Server):

- Security Mechanism: STS Issued Token
- KeyStore: Yes, Alias: None
- Truststore: Yes, Alias: None

3) Client. 2 Web Services references:

+ Service Provider reference:
- KeyStore: Yes , alias: xws-security-client
- Truststore: Yes, alias: xws-security-server
- Security Token Service Endpoint: http://localhost:8080/MySTSProject/MySTSService

+ STS reference:
- KeyStore: Yes, alias: xws-security-client
- Truststore: Yes, alias: wssip
- SAML Callback Handler: xwss.saml.SamlCallbackHandler

The problem is that when the client accedes to the Service Provider, passing the Token issued by the STS to it, the Service Provider gives a error while resolving the KeyIdentifier.

This is the complete stack trace:

[i]javax.xml.ws.soap.SOAPFaultException: WSS1816: Error occurred while resolving KeyIdentifier
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java :187)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:116)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:254)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke (SyncMethodHandler.java:224)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:117)
at $Proxy38.sayHello(Unknown Source)
at javaapplication3.Main.(Main.java:29)
at javaapplication3.Main.main(Main.java:47)
Caused by: com.sun.xml.wss.XWSSecurityException: WSS1816: Error occurred while resolving KeyIdentifier
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityTokenProcessor.processKeyIdentifier (SecurityTokenProcessor.java:395)
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityTokenProcessor.resolveReference(SecurityTokenProcessor.java:134)
at com.sun.xml.ws.security.opt.impl.incoming.processor.KeyInfoProcessor.processKeyInfo (KeyInfoProcessor.java:132)
at com.sun.xml.ws.security.opt.impl.incoming.processor.KeyInfoProcessor.getKey(KeyInfoProcessor.java:118)
at com.sun.xml.ws.security.opt.impl.incoming.Signature.process(Signature.java :274)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:385)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java :264)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:219)
at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.verifyInboundMessage(WSITServerAuthContext.java :471)
at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java:297)
at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java :211)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:168)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java :129)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java :554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle (ServletAdapter.java:135)
at com.sun.enterprise.webservice.JAXWSServlet.doPost(JAXWSServlet.java:159)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
at javax.servlet.http.HttpServlet.service (HttpServlet.java:831)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java :290)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke (WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:270)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess (DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask (DefaultReadTask.java:339)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java :212)
at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: javax.xml.crypto.KeySelectorException: java.lang.NullPointerException
at com.sun.xml.ws.security.opt.impl.incoming.KeySelectorImpl.resolveKeyIdentifier (KeySelectorImpl.java:733)
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityTokenProcessor.processKeyIdentifier(SecurityTokenProcessor.java:392)
... 51 more
Caused by: java.lang.NullPointerException
at com.sun.xml.wss.impl.misc.SecurityUtil.initInferredIssuedTokenContext(SecurityUtil.java:416)
at com.sun.xml.ws.security.opt.impl.incoming.KeySelectorImpl.resolveKeyIdentifier(KeySelectorImpl.java :723)
... 52 more
[/i]

But if I use “SAML Sender Vouches with Certificates” authentication in the STS then everything works perfectly. Which can be the problem?

Thank you very much!

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Your scenario description is perfectly valid and WSIT should support it, although we don't have testcases covering this scenario. We would like to make sure it works and we will fix any bugs that you may be encountering.

From the stack traces it appears you have old code because i am unable to match up the line numbers from the stack traces.

Would you mind giving another try using the latest WSIT from :

https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=5472&e...

you just have to install these latest bits onto GlassFish using the installer.

------------------------------------------------
The root cause seems to be the NPE :
Caused by: java.lang.NullPointerException
at com.sun.xml.wss.impl.misc.SecurityUtil.initInferredIssuedTokenContext(SecurityUtil.java:416)

And this can only happen if the SAML Assertion issued by the STS does not contain a SubjectConfirmation KeyInfo. Can you send us the SAML assertion issued by the STS.
-------------------------------------------------

Also i am a bit surprised that if you use "SAML Sender Vouches with Certificates” as the profile for STS then everything works fine.

This seems to indicate to me in the case where it fails (which is what you are testing), the STS is somehow having an IssuedToken in its WSDL ( is that true ?).

Since everything has been developed with NB, can you send us the NB projects of the client, server and STS. (you can send it to me directly at vbkumar.jayanti@sun.com)

Thanks.

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Just trying to understand : Are you saying you do not want to use the IssuedToken Policy Assertion (thereby making it a Two Party Scenario, NO STS).

1. Do you want the Server to return the Signed SAMLAssertion in the Message Payload or in the SecurityHeader.

2. Do you also want to secure the Response Message (sign/encrypt it any way ?).

Thanks.

ernestojpg
Offline
Joined: 2005-10-09

Hi kumarjayanti !

Exactly. I need that the client sends to the Server one o several SAML Tokens with attributes (its access credentials) and with the Client Public Key (at least). The server must capture this Token, process it, and respond to the client with a new SAML Token with a AuthorizationDecisionStatement (not a AttributeStatement).

> Just trying to understand : Are you saying you do
> not want to use the IssuedToken Policy Assertion
> (thereby making it a Two Party Scenario, NO STS).

I would not like to use a STS, because I need to have more flexibility.

> 1. Do you want the Server to return the Signed
> SAMLAssertion in the Message Payload or in the
> SecurityHeader.

This is not important for me. I only need that the client can easily capture this Token (that issues the server)

> 2. Do you also want to secure the Response Message
> (sign/encrypt it any way ?).

I only need that the SAML Token with the AuthorizationDecisionStatement is signed by the Server.

Thanks!!

jdg6688
Offline
Joined: 2005-11-02

Here the server just validate the client SAML token and issue another SAML token to the client (and presumable the client will use the issued SAML token with another service). This is exactly what an STS does as a Web service.

Do you have the other business logic for the server?

jdg6688
Offline
Joined: 2005-11-02

In particular, I'd like to understand what you mean by "have more flexibility" and to see if STS with all its extensiblity as defined in the spec can satisfies you requirement.

ernestojpg
Offline
Joined: 2005-10-09

Hi,

I have been reading in the forum the things that can be done with a STS, and I am studying if it could be good for me.

In order to obtain that the client passes a SAML Token with attributes to the STS, I could use the Holder-of-key security mechanism in the STS.

I have tried to make an example with this, and I have obtained that the client sends the RequestSecurityToken with attributes to the STS, and the STS responds to him with the RequestSecurityTokenResponse. I have used the SamlCallbackHandler.java of the WSIT tutorial.

The problem is that when the client accedes to the Service Provider, passing to it the Token emitted by the STS, the Server gives a failure '[i]WSS1816: Error occurred while resolving KeyIdentifier[/i]'.

I suppose that the Client does not construct a correct holder-of-key Token in the SamlCallbackHandler. What can be the problem?

Thanks!

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Not sure i understood what you are doing.

1. The SAMLCallbackHandler can be used in scenarios where the SecurityPolicy of the ServiceProvider has a token.

2. When the SecurityPolicy of the ServiceProvider has then an STS is actually used and the WSIT Client side runtime contacts the STS to obtain the SAML Assertion.

From what you have written, it appears you have used the SAMLCallbackHandler and inside it you tried to contact an STS and get back the SAMLAssertion is that correct ?.

The Error Message which you are seeing will happen if

1. SAML Assertion was not present in the message sent to ServiceProvider
2. Or the HOK saml assertion's SubjectConfirmation is referring to a certificate which could not be located in the ServiceProvider's truststore.

Can you send us the complete stack trace and also the SAMLAssertion or the Complete Message sent to ServiceProvider.

Thanks

jdg6688
Offline
Joined: 2005-11-02

It is a case that the client send one SAML token to the STS and STS returns another SAML token for the client to access the service.

Other than the stack trace and the message to the service. Please send the WSDL of the STS. Make sure the Issued SAML token is not encrypted so we can see it.