I am experimenting with PicketLink STS with a web app and a web service.
I'm able to setup my web app with the authentication via the STS with no problem (just using the sales example app as a guide).
As defined in the usage scenarios here http://community.jboss.org/wiki/PicketLinkSTS-UsageScenarios
It's clear that I should be able to grab the current user's assertion, then forward it on to the down stream service for authentication.
// get the assertion
SAMLPrincipal principal = (SAMLPrincipal) this.context.getCallerPrincipal();
Element assertion = principal.getAssertionElement();
// insert the assertion in the request
Is this still a supported scenario? It looks like the API has changed since that wiki article was published. I keep getting a class cast exception...
The offending code, crashes at 67
67: SAMLPrincipal principal = (SAMLPrincipal) request.getUserPrincipal();
68: org.w3c.dom.Element assertion = principal.getSAMLCredential().getAssertionAsElement();
69: contextPCS.put("org.picketlink.trust.saml.assertion", assertion);
.ClassCastException: org.jboss.security.SimplePrincipal cannot be cast to org.picketlink.identity.federation.core.wstrust.SAMLPrincipal
Perhaps I'm going about this the wrong way and there is another pattern I should be following. Any ideas?
I am running the 2.0.1 build and the class type for request.getUserPrincipal from the context of the web app is something like SimplePriniciple. Type casting this fails. I do see that there is a session attribute that gets me to a picketlink principal but the object required is actually a SAML20 Authorization Handler (or something like that). So it seems that getting the SAML xml from the currently signed in user isn't possible. T
Moreover, from the context of the JSP web app, I started building out an STSClient request to get a new token for the user signed in to the web app (so that it can talk to the web services). I've read your note on OnBehaveOfType and what the WS-Trust 1.4 spec says on it (which version of WST is picketlink using?). In the picketlink code, OnBehaveOfType is xs:Any. The spec is also rather vague,...
This OPTIONAL element indicates that the requestor is making the request on behalf of another. The identity on whose behalf the request is being made is specified by placing a security token,<wsse:SecurityTokenReference> element, or <wsa:EndpointReference> element within the <wst:OnBehalfOf> element. The requestor MAY provide proof of possession of the key associated with the OnBehalfOf identity by including a signature in the RST security header generated using the OnBehalfOf token that signs the primary signature of the RST (i.e. endorsing supporting token concept from WS-SecurityPolicy). Additional signed supporting tokens describing the OnBehalfOf context MAY also be included within the RST security header.
A wsa:EndpointReference is sort of applicable, but do I need to provide the URL of the web app or the web service?
STR is applicable, but only if I can get a copy of it from PL
I'm not sure where to go from here. I have the PL source, but I'm not really sure where I need to be poking around to find out what's really happening. Does the STS actually support this or not?
So I've made some progress....
Element assertion = client.issueTokenOnBehalfOf(url of the service to be executed, SAMLUtil.SAML2_TOKEN_TYPE, request.getUserPrincipal());
This will be me an assertion from the web app about the current user.
From here, I can programmatically attach the assertion to the request context and add the SAML2Handler to the chain. I've also confirmed that the assertion is infact attached to the message to the service.
For the service being executed, I have the handler SAML2Handler added to the chain via the config file, however the service will execute with or without the saml assertion and it does not appear to be setting the WebServiceContext at all. What am I missing?
Edit: some additional information. I see the following log entry AFTER the service has already been executed.
WARN [org.picketlink.trust.jbossws.handler.SAML2Handler] Inbound::We did not find any assertion
Edit: This warning message is displayed if the SAML2Handler is either in the pre-handler-chain or the post-handler-chain.