Skip to main content

How to retrieve token assertion attributes like ,?

29 replies [Last post]
markus_franke
Offline
Joined: 2007-10-10

Is it possible to retrieve the token assertion attributes like ,, and so on somehow? The callbacks (e.g. SAMLCallback, NameCallback) do not provide them.

I can specify via the wsit-client.xml different SAMLHandlers for each service, but I cannot specify different SAMLHandlers for different assertions specified in the WSDL. Thus I would like to dispatch inside the SAMLHandler, but for it I have to access information like or .

Reply viewing options

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

> As for the stuff, if getting them as
> runtime props is a requirement then you will have to
> file an RFE and then we will evaluate the feasibility
> of making that available either as runtime props..

Done, see https://wsit.dev.java.net/issues/show_bug.cgi?id=795

kumarjayanti
Offline
Joined: 2003-12-10

We have checked in a Fix, yet to test the case.
Can you check and let us know if this is working already.

You will need to download the latest WSIT nightly : https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=5472&e...

In your SAML CBH you need to call the following code :

SAMLCallback cb = ...
Map props = cb.getRuntimeProperties();
com.sun.xml.wss.TokenPolicyMetaData metaData = new
com.sun.xml.wss.TokenPolicyMetaData(props);

String issuer = metaData.getIssuer();
org.w3c.dom.Element claims = metaData.getClaims();

Message was edited by: kumarjayanti

markus_franke
Offline
Joined: 2007-10-10

I tried wsit-2008-02-20 and metro-2008-02-21 but both throw

at com.sun.xml.ws.security.impl.policyconv.XWSSPolicyGenerator.collectPolicies(XWSSPolicyGenerator.java:293)
at com.sun.xml.ws.security.impl.policyconv.XWSSPolicyGenerator.process(XWSSPolicyGenerator.java:159)
at com.sun.xml.ws.security.impl.policyconv.XWSSPolicyGenerator.process(XWSSPolicyGenerator.java:154)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.constructPolicyHolder(SecurityPipeBase.java:1241)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.constructPolicyHolder(SecurityPipeBase.java:1234)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.addOutgoingMP(SecurityClientPipe.java:569)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.collectPolicies(SecurityPipeBase.java:782)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.(SecurityPipeBase.java:288)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.(SecurityClientPipe.java:127)
at com.sun.xml.ws.assembler.TubelineAssemblyController$SecurityTubeAppender.appendTube(TubelineAssemblyController.java:435)
at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$WsitTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:79)

when invoking new XService().getXServicePort() for a service that does not use WS-SecurityPolicy in its WSDL file. For services that use security it's working.

effectivePolicy in XWSSPolicyGenerator seems not to be set. This might be true, but why is TubelineAssembleyController trying to instantiate a SecurityClientPipe? It seems that TubelineAssembleyController.isSecurityEnabled() evaluates to true somehow.

Message was edited by: markus_franke

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Are you saying that all non-secure cases fail with the above expcetion when you take the lates t Builds.

Still unclear whether you were able to access the Issuer and Claims info in the Secure Cases ?.

markus_franke
Offline
Joined: 2007-10-10

Soory, this was a little bit unclear.

> Hi,
>
> Are you saying that all non-secure cases fail
> with the above expcetion when you take the lates t
> Builds.
>

Yes. With the mentioned build the instantiation of a service port for a non-secured port crashes with the above stated stacktrace.

> Still unclear whether you were able to access the
> Issuer and Claims info in the Secure Cases ?.

After modifying my test client (removing the dependency to the port for the non-secured service) I was able to run the test client: The issuer is set as desired. But the claims and claimsDialect members are null (also in TokenPolicyMetaData._featureBinding class). I used



ritzmann
Offline
Joined: 2003-06-19

The symptoms you are describing look exactly like a bug I fixed on Friday: https://wsit.dev.java.net/issues/show_bug.cgi?id=816

Could you please check if the latest nightly build fixes your problem: https://metro.dev.java.net/servlets/ProjectDocumentList?folderID=8717&ex...

markus_franke
Offline
Joined: 2007-10-10

Thanks.

The non-secured service port is working now. But the claims / claimsDialect property is still null.

ashutoshshahi
Offline
Joined: 2006-01-27

> The non-secured service port is working now. But the
> claims / claimsDialect property is still null.

We return entire claims element as a DOM element and leave i to the user to parse it and verify the information (dialect, different claims etc). Are you saying this getClaims() method returns NULL? If yes, can you attach your wsdl or paste the relevant section of your wsdl?

Ashutosh

markus_franke
Offline
Joined: 2007-10-10

Yes, getClaims() returns NULL. Here the sp:SupportingTokens section:






http://localhost:5080/dirxaccess-efa-accesstoken/dedicatedclient










ashutoshshahi
Offline
Joined: 2006-01-27

>
> > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07
> /securitypolicy/IncludeToken/AlwaysToRecipient">

Please not that wst:Claims, sp:IssuerName inside Tokens have been introduced only in SecurityPolicy 1.2 version, and were not present for 2005/07 namespace. So you will have to use http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 namespace for SecurityPolicy.

Ashutosh

kumarjayanti
Offline
Joined: 2003-12-10

> Note that this feature would be also nice for
> UsernameCallback and PasswordCallback (these are
> currently ordinary NameCallback resp.
> PasswordCallback).
>
Since atleast 2 people have asked for this we added support for this, please see :
http://forums.java.net/jive/thread.jspa?messageID=256734

markus_franke
Offline
Joined: 2007-10-10

Which properties can I expect in the runtimeProperties map? I.e. which classes contain the constants defined for these property names?

kumarjayanti
Offline
Joined: 2003-12-10

Which properties depends on whether you are on the client or server side.

Mostly it will be the properties defined in JAXWS BindingProvider.

If you set any properties on BindingProvider.RequestContext they should be available to you.

On the Server side. It will be any JAXWS spec defined properties and com.sun.xml.wss.impl.MessageConstants.AUTH_SUBJECT

It seems the latest build is available now can you try this :
https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=5472&e...

markus_franke
Offline
Joined: 2007-10-10

> I'd like to add the following question to this
> thread:
>
> Is it possible to retrieve the token assertion
> attributes like ,,
> at the service side?
>
> For example, I'd like to collect information to form
> a XACML context request containing issuer, name
> identifier, and the like.

Thanks. I am currently testing it. It provides me on client side in the SAMLCallbackHandler:

SignatureConfirmation=[]
EnableWSS11PolicySender=true

It does not contain sp:Issuer/wsa:Address from WSDL.

Message was edited by: markus_franke

kumarjayanti
Offline
Joined: 2003-12-10

>SignatureConfirmation=[]
>EnableWSS11PolicySender=true
These above are some impl specific props that will go away.

As for the stuff, if getting them as runtime props is a requirement then you will have to file an RFE and then we will evaluate the feasibility of making that available either as runtime props..

On the therhand if you know the info in your client code then you can just set those as properties on your Proxy ((BindingProvider)proxy).getRequestContext().put("issuer", "xyz");

and then it will be available to you in the SAML CBH.

markus_franke
Offline
Joined: 2007-10-10

> >SignatureConfirmation=[]
> >EnableWSS11PolicySender=true
> These above are some impl specific props that will go
> away.
>
> As for the stuff, if getting them as
> runtime props is a requirement then you will have to
> file an RFE and then we will evaluate the feasibility
> of making that available either as runtime props..
>
> On the therhand if you know the info in your client
> code then you can just set those as properties on
> your Proxy
> ((BindingProvider)proxy).getRequestContext().put("iss
> er", "xyz");
>
> and then it will be available to you in the SAML CBH.

I guess that's not feasible for me: I am running at least 2 Web services each requesting 2 SAML assertions via sp:SupportingTokens. Thus I implemented a SAMLCallbackHandler that is used for both Web services and is invoked twice by the WSIT stack: one time for the one assertion and another time for the other assertion.

So far as I see the callbackhandlers are instantiated per Web service, i.e. I have 2 callbackhandler instances. But when the callbackhandler is invoked it does not know
a) which Web service is requesting a SAML assertion
b) which type of SAML assertion is requested

Problem a) can be resolved by implementing a Web service specific handler or by the putting some information into the RequestContext as you mentioned above.

But b) can only be resolved when information taken from the WSDL is put into the RuntimeProperties by WSIT stack.

markus_franke
Offline
Joined: 2007-10-10

Switching to the new sp-namespace works as expected.

Thanks.

edubuis
Offline
Joined: 2005-06-28

I'd like to add the following question to this thread:

Is it possible to retrieve the token assertion attributes like ,, at the service side?

For example, I'd like to collect information to form a XACML context request containing issuer, name identifier, and the like.

jdg6688
Offline
Joined: 2005-11-02

There information are in the WSDL. it is not available.

On the other hand, you may get Issuer and the attributes etc from the credentials (SAML assertions) for your XACML call ?

jdg6688
Offline
Joined: 2005-11-02

These attributes only available in the new standarrd version of ws-securitypolicy, exception the IssuedToken.
We have not supportted them yet. But they are the ways to distinguish the same type
of tokens in a message.

markus_franke
Offline
Joined: 2007-10-10

Will you support them in the near future?

kumarjayanti
Offline
Joined: 2003-12-10

If i understood correctly you need info from some of the assertions inside the IssuedToken assertion (such as issuer etc) when handling the SAML Callback on the client side, is that correct ?.

Each CallbackHandler has access to a runtime properties map. We could potentially make the etc as runtime properties if that works for you. Is there a list of things that you would need ?.

Probably you need the contents of the entire IssuedToken Assertion ?. I still have to check how on the client side we would access them so as to make them available for the SAML Callback.

On the other hand if you wish to set some properties in your client code which you want visible inside the SAML Callback then you can do so by casting your proxy to a BindingProvider and then set some properties on the requestContext. Inside the SAMLCallbackHandler you can access those [ properties :

Client Code :
-----------------
((BindingProvider)proxy).getRequestContext().put(, );

Inside SAML CBH
--------------------------
String mypropValue = samlCallback.getRuntimeProperties().get();

Let me know if that helps in anyway.

Thanks.

markus_franke
Offline
Joined: 2007-10-10

> Inside SAML CBH
> --------------------------
> String mypropValue =
>
> amlCallback.getRuntimeProperties().get()
> ;
>
> Let me know if that helps in anyway.
>
>
> Thanks.

getRuntimePropertimes() would be sufficient for me. My logging in the AliasSelector shows a lot of useful content, but the RuntimeProperties provided in the SAMLCallback are currently empty, isn't it?

Note that this feature would be also nice for UsernameCallback and PasswordCallback (these are currently ordinary NameCallback resp. PasswordCallback).

Thanks.

kumarjayanti
Offline
Joined: 2003-12-10

>
> getRuntimePropertimes() would be sufficient for me.
> My logging in the AliasSelector shows a lot of useful
> content, but the RuntimeProperties provided in the
> SAMLCallback are currently empty, isn't it?

This should be fixed if you take tomorrows nightly or the latest workspace right now.
>
> Note that this feature would be also nice for
> UsernameCallback and PasswordCallback (these are
> currently ordinary NameCallback resp.
> PasswordCallback).

The idea was to make use of whatever exists in Java Standard in favor of proprietary API's.

The runtimeProperties on a callback is an XWSS 2.0 feature that is being carried over to Metro/WSIT

But we have a way (slightly longish way). You can define your own XWSSCallbackHandler in which case you can actually get UsernameCallback and PasswordCallback dispatched to your custom callbackhandler.

markus_franke
Offline
Joined: 2007-10-10

> >
> > getRuntimePropertimes() would be sufficient for
> me.
> > My logging in the AliasSelector shows a lot of
> useful
> > content, but the RuntimeProperties provided in the
> > SAMLCallback are currently empty, isn't it?
>
> This should be fixed if you take tomorrows nightly or
> the latest workspace right now.

The download page provides still the version 2008-01-17. When I calculate correctly (you in Indian time zone, I in MET zone, server in Pacific Time zone ?) this version does not contain the fix, right?

kumarjayanti
Offline
Joined: 2003-12-10

yes, it does not. I will check with people who look after this and get back tomorrow.

kumarjayanti
Offline
Joined: 2003-12-10

Can you try this :

https://metro.dev.java.net/servlets/ProjectDocumentList?folderID=8118&ex...

It says 1.1.x but seems it is actually Metro 1.2.

markus_franke
Offline
Joined: 2007-10-10

> Can you try this :
>
>
> ttps://metro.dev.java.net/servlets/ProjectDocumentList
> ?folderID=8118&expandFolder=8118
>
> It says 1.1.x but seems it is actually Metro 1.2.

I tried 2008-01-25 and 2008-01-28, but runtimeProperties is still emtpy.

kumarjayanti
Offline
Joined: 2003-12-10

yes, sorry about that, there is a problem with the build and i have notified our folks about it.

Will get back once we have the correct build.