How can I use Attribute Certificates in my WSIT applications?
I use standar Java SE 5 library to use X509 Public Key Certificate, but there isn't a X509 Attribute Certificate.
Also when I use SAML there is no username /pwd authentication happening on the server. Is this the default behaviour. How does SAML takes care of authentication . I am using Tomcat as the app server
Please create a different thread and i will reply there :-).
So, is not possible to get the X509 certificate's attribute in the last version of wsit? Are there any plans to support this feature in the near future?
The workaround to this, is using SAML or is another one with X509?
Yes, I think that a stateful web service is required. Until now, I had used HTTP sessions to store the Web Service state. But now, I'm planning to use the @HttpSessionScope annotation. I still haven't tested it.
Take a look at this page: https://jax-ws-commons.dev.java.net/http-session-scope/
OK, I think that it will not be a problem for me. I suppose that I can cache the Assertion inside my Webservice the first time I read it.
I have tested the mechanism in a STS scenario, with Secure Conversation between Client and the Server, and it work fine too! (I can access to the STS Token in the Server side)
Thank for your rapid reply! And good job! ;)
Great job kumarjayanti !
I have tried it in a Holder-of-key Scenario and I was able to Grab the SAML Assertion even after SecureConversation was enabled. I used the [i]com.sun.xml.wss.util.SAMLUtil.createSAMLAssertion(xmlStreamReader)[/i] function to obtain the SAML Assertion.
In the first Client call to the Server, I can obtain the SAML Assertion from the xmlStreamReader correctly, but in the second Client call to the Server, I only can obtain the following:
Is that normal?
I have been testing the SAMLAssertionFactory class to create an Asssertion from a xmlStreamReader, and it work fine. Good job!
But because I think that I can't to obtain too much information of a Assertion object, I have preferred to use the SAMLUtil class to create a Element instance with the entire SAML representation.
I have been testing the SAMLUtil class to create a Element instance from the xmlStreamReader, but I have a problem. I have used it in a STSAttributeProvider of a STS Service:
public class MySTSAttributeProvider implements STSAttributeProvider
public Map> getClaimedAttributes(Subject subject, String appliesTo, String tokenType, Claims claims)
It is a very good news! You are the best ones ;)
And another thing, Is now possible that a CertificateValidator or any other form of PostValidation Hook to check the attributes and make a access decision (for example)? I'm using Glassfish and a JSR-196-compliant Web Service, and for that reason the CertificateValidator is not called :(
Do you know when (o in what version) the Credentials will be available in the subject during the method call? (in a Secure Conversation)
And, Do you have the utility class to parse the XMLStreamReader into a Java Object (that implements the com.sun.xml.wss.saml.Assertion interface)? It could be very useful for my :)
Thank you very much!
I think that it is normal that it is not possible to accede to SAML Token in the method call, because SAML Token only goes in the first message (establishment of the Secure Session) before the method call.
But when the Secure Session is establishing, does not take place any CallBack (or a method call) that the developer can intercept to obtain Token SAML?
Thank you very much kumarjayanti, now I can get the SAML Token when the client calls to a Web Service method. Example of Web Service:
public class Hello
private WebServiceContext wsContext;
public String sayHello(@WebParam(name = "name") String name)
Subject subj = com.sun.xml.wss.SubjectAccessor.getRequesterSubject(wsContext);
Ok, I can get the Sender Subject with the getRequesterSubject() method. But, how can I access to the whole SAML assertion, or to the attributes?
And yes, when the server receives the certificate It must to verify the attributes and It must to make some access decision. But this cannot be done by the WSIT runtime but by a validador provided by the developer, isn't it?
I'm using WSIT on GlassFish.
I need to pass Attributes Certificates to a Web Service. If I do it using SAML Tokens, could I pass many SAML Tokens in same SOAP Header? How could I obtain these attributes in the Web Service?
Another alternative is to use Extensions of the X509 certificates, or to use Attribute Certificates of other libraries (Bouncy Castle, iaik,â€¦)
Some suggestion? :-)
You can pass multiple attributes in a Single SAML assertion. The SAML assertion would be available as a public credential inside the Sender's Subject.
The Sender Subject can be accessed as :
Subject subj = com.sun.xml.wss.SubjectAccessor.getRequesterSubject(WebServiceContext ctx)
Yes you can definitely use Extensions today. But what is the processing that you expect the Reciever of Such a Cert to do ?.
I mean what does the Runtime on the Server Side need to do when it recieves such a cert ?.
Would you like the Runtime to callback on a Developer Supplied Validator where the Certificate (with extensions) is passed so that developer can make some access decisions ?.
BTW are you using WSIT on GlassFish or TOMCAT ?.
WSIT Security has no explicit support X.509 Attribute Certificates right now.
The closest Idiom that we support today in WSIT is WS-Trust where the Attribute Information is encoded inside SAML assertions by the Issuing Identity Provider.
This thread was about AttributeCertificates. If what you are looking for is Attributes of an X509Certificate of the Client then that is possible. You can access to the X509Certificate of the client on the Server side. Is that what you are looking for ?.
Sorry, I misundertood the post, but yes, what you are saying is what I'm looking for? How can I access those atributes from a service? Do I have to use the webServiceContext class?
yes you will need the WebServiceContext.
You can call
Subject subj = com.sun.xml.wss.SubjectAccessor.getRequesterSubject(webserviceContext);
if the client request message had the certificate then you should see the cert in the public credential set of the Subject.
Thank you very much! That solved part of the problem. The other part is that I wanted to integrate this with JAAS. Is there any integration of this with JAAS?
mistakes while writing
Message was edited by: gllambi
What do you want JAAS for and at which point ?.
Within your service impl you are free to use JAAS if you need to, but i guess you are talking about plugging in JAAS before that for some Authentication ?.
Please explain what your usecase.
Maybe that can solve my problem. I' ve already have some users in my system, but now I want to map them with certificates. What I've noticed, is that the principal is not filled with the CN of the cert. It would be nice if I could have something like this:
/* principal name filled with certifcate's CN */
Principal pUser = webServiceContext.getUserPrincipal()
Is there a way to do so?
Thanks a lot!
But, how can I "cache" those assertion at service side ?
Do we need to use stateful web service ?
> In the first Client call to the Server, I can obtain
> the SAML Assertion from the xmlStreamReader
> correctly, but in the second Client call to the
> Server, I only can obtain the following:
> Is that normal?
If you disable SecureConversation then you should see the complete Assertion in the Second Call as well. Otherwise you have hit a possible bug.
Actually i think the reason why the second call is returning Empty is because the XMLStreamReader wraps an InputStream underneath. And once you read-out an InputStream you cannot read again from it.
So is this an issue for you ?. Can you not cache the Assertion inside your Webservice the first time you read it. Because the credential is not going to change for this particular secure session anyway...
But nevertheless it is a side-effect of the fact that we have an XMLStreamReader. If you switch to the Non-Streaming Mode you should always get the Assertion DOM Element in every call (not just the first one). Thanks for bringing this to our notice.
We will have to think and see if anything can be done in this case without sacrificing performance.
It could be another bug. I will check and fix it.
It was indeed another bug, sorry for all the trouble. It is fixed now and i tested it out properly. You can download the nightly that is going to come tomorrow.
We are still working on your other requirement that SC Bootstrap credentials be made available in the Subject. Will update once we have that.
> We are still working on your other requirement that
> SC Bootstrap credentials be made available in the
> Subject. Will update once we have that.
I have made a fix for this today in the XWSS workspace and will make it available in WSIT nightly build by early next week.
You should then be able to access the SecureConversation Bootstrap Credentials from the RequesterSubject.
> > We are still working on your other requirement
> > SC Bootstrap credentials be made available in the
> > Subject. Will update once we have that.
> I have made a fix for this today in the XWSS
> workspace and will make it available in WSIT nightly
> build by early next week.
> You should then be able to access the
> SecureConversation Bootstrap Credentials from the
Done, please pickup Thursday (Sept 13th) Nights Nightly WSIT build and you should have it. I have tested a Scenario where i was able to Grab the SAML Assertion even after SecureConversation was enabled.
I am also working on your other requirement for Certificate PostValidation. Will update you once done.
We are working on the PostValidation Support for Certificate's....I will get back to you on this.
We have added API's to create SAMLAssertion or a DOM Element out of the XMLStreamReader. You will need to pick up the latest Nightly build for this (please pick up Aug 28th nightly for this):
Here is what the API looks like :
To create a DOM Element representing the Assertion :
Element element = com.sun.xml.wss.util.SAMLUtil.createSAMLAssertion(xmlStreamReader);
If you would like to create a com.sun.xml.wss.saml.Assertion then here are the steps.
//assuming the assertion was a SAML 2.0 assertion
SAMLAssertionFactory factory = SAMLAssertionFactory.getInstance(SAMLAssertionFactory.SAML2_0);
Assertion assertion = factory.createAssertion(xmlStreamReader);
Let us know if it worked....
Message was edited by: kumarjayanti
Wooo! It is absolutely perfect! :D
I will prove it, and I let you know if it worked.
If you are trying the feature please use Aug 31 (tonight's) nightly build. Because another user tried and found an NPE issue. I fixed the issue just now.
Also there is a correction (i mentioned SAMLAssertionFactory.getInstance() earlier, it should actually be SAMLAssertionFactory.newInstance()).
//assuming the assertion was a SAML 2.0 assertion
SAMLAssertionFactory factory = SAMLAssertionFactory.newInstance(SAMLAssertionFactory.SAML2_0);
Assertion assertion = factory.createAssertion(xmlStreamReader);
I am tring to configure SAML over SSL.
My SAML callback handler is getting called(using the same SAML handler you have posted). I dont see the saml attributes getting added to the SOAP request.
to print SOAP message to the console. I want to put some access control based on SAML attributes.
>Do you know when (o in what version) the Credentials will be available in the subject during the >method call? (in a Secure Conversation)
we are working on this.
>And, Do you have the utility class to parse the XMLStreamReader into a Java Object (that >implements the com.sun.xml.wss.saml.Assertion interface)? It could be very useful for my :)
At least one more user is stuck on this. So i think i will raise the priority on this as well, but this one will take some time.
Any volunteers ?...
Just give us a few days, we will put out a Utility to convert the XMLStreamReader to a DOM Element. Once we have the DOM Element i guess you can use it directly or also convert the DOM Element easily to com.sun.xml.wss.saml.Assertion
I will update you once i have it ready.
Yes, we do not intend to make any callback during the Secure Session Bootstrap,
however we intend to make the Credentials used during Bootstrap to be available in the subject during the method call.
Sorry to say but this is another known issue. Currently, the Bootstrap client credentials are not available to the Service during the method call.
We will be fixing this.
The SAML Assertion is currently available in the Subject in two forms :
By default (if you are using latest WSIT nightly builds) then you should see an XMLStreamReader instance inside the public credentials. You would have to read from the reader and create your own SAML Assertion representation.
If you swith off Streaming Security (which results in a drop in performance) then in that case you should be able to acess the SAML Assertion as a DOM Element inside the Public Credentials of the Subject.
You can switch off streaming security by following instructions in the blog :
(but we would generally not advise you to do so because there could be loss of performance)
In future we may provide a Utility class to parse an XMLStreamReader representing a SAML Assertion into a Java Object that implements the com.sun.xml.wss.saml.Assertion interface.
On the Certificate side, yes you would have to do the access decision and attribute checks inside a developer specified Validator.
So are you able to configure a CertificateValidator and is it being Called ?.
If you have used NetBeans to develop the App then chances are the Validator is not being Called. This happens because on GlassFish we make use of the JSR 196 defined Callbacks which are generally intended to be supplied by the Container.
However it turns out that by depending on JSR 196 Callbacks developers are running into exactly the same issue that you have (which is to do some extra attribute/extension validation on the recieved certificate). Because the JSR 196 Callbacks leave the Certificate Validation function to the WSIT Runtime instead.
So we will very soon add support for the CertificateValidator or Some other form of PostValidation Hook to allow developers to do this. I will try to do this early next week and let you know.
If you are running on TOMCAT however then the CertifcateValidator will be called and it is the developers responsibility to do the entire certificate validation process in addition to any extra attribute/extension checking.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.