Hi Oliver, Thanks, the tomcat-idp.jks was the keystore I was looking for.
However, I cannot make the 1.1.0-SNAPSHOT IDP running. I am using the same Tomcat as for 1.0.0, I only replace the keystore for the HTTPS connector. I simply deploy the STS and IDP. The STS WSDL is available as always. But when I access the IDP, nothing happens. I put this in a browser: https://localhost:9443/fediz-idp/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet%2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F In the Tomcat console I see this: --- ************************************************************ Request received for '/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet %2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F': org.apache.catalina.connector.RequestFacade@559081 servletPath:/federation/ pathInfo:null Security filter chain: [ STSPortFilter SecurityContextPersistenceFilter BasicAuthenticationFilter RequestCacheAwareFilter SecurityContextHolderAwareRequestFilter AnonymousAuthenticationFilter SessionManagementFilter ExceptionTranslationFilter FilterSecurityInterceptor ] ************************************************************ Jun 04, 2013 10:33:09 AM org.apache.cxf.fediz.service.idp.STSPortFilter doFilter INFO: STSAuthenticationProvider.wsdlLocation set to https://localhost:9443/fediz-idp-sts/STSService?wsdl --- But the request is not redirected, and I get back simply HTTP 404. In case of 1.0.0 this was working, a SAML token was generated and the browser was redirected. I am using the latest Fediz from github. Can you please let me know, how this new release is working? I see that many things have changed, now there is no IDPServlet, but Spring Security, and I am a bit lost. And how do you expect, when do you release the 1.1.0 final? Kind regards, Ivan 2013/6/3 Oliver Wulff <[email protected]> > Hi Ivan > > The IDP doesn't trust somebody. Instead, the application (relying party) > trusts the IDP/STS. In this case, the signer is within the stsstore.jks: > > http://svn.apache.org/viewvc/cxf/fediz/trunk/services/sts/src/main/resources/stsstore.jks?view=log > This certificate hasn't been changed. > > But maybe you mean the communication between the IDP and STS where the > tomcat keystore of the STS must be in the certificate chain of the IDP to > establish an SSL connection successfully. > > The following html page illustrates the usage of the different keys: > > http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/HowToGenerateKeysREADME.html?view=co > > You must use the tomcat-idp.jks for the https settings in tomcat: > > http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/tomcat-idp.jks?view=log > > HTH > > Oli > > ________________________________________ > From: Iván Brencsics [[email protected]] > Sent: 03 June 2013 12:24 > To: [email protected] > Subject: Re: WS-Trust token handling > > Hi Oliver, > > Thanks for your answers, all you recommened has been working. I followed > your blogs, and managed to make running the STS, IDP, RP, and the web > service client (with tomcat plugin). But only with the 1.0.0 version. In > case of later Fediz releases there is problem with the tomcat keystore. > > * In 1.0.0 the tomcat keytstore has a key with the following cert: > CN=localhost, SHA1: FE:B6.... The IDP has this cert in its truststore > * In 1.1.0-SNAPSHOT the IDP trusts this cert: CN=localhost, SHA1: A6:BC... > > I know very well that I could generate the keys/keystores by myself, but > first I would prefer running your examples as they are, as they come out > from github. Could you please share with me the tomcat keystore you are > using currently, that the current IDP trusts? > > Thank you very much, kind regards, > Ivan > +49 179 3814022 > > > > > > 2013/5/27 Oliver Wulff <[email protected]> > > > Hi > > > > 1) Yes, CXF supports caching the token per user dependent on AppliesTo > and > > Lifetime. So each component must have a different AppliesTo value. > > > > 2) This is supported. Just use the WebServiceContext API. Fixed here: > > https://issues.apache.org/jira/browse/CXF-4212 > > > > The following example uses this API: > > > > > http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/webservice/ > > > > 3) Never tested. > > > > Thanks > > Oli > > > > > > ------ > > > > Oliver Wulff > > > > Blog: http://owulff.blogspot.com > > Solution Architect > > http://coders.talend.com > > > > Talend Application Integration Division http://www.talend.com > > > > ________________________________________ > > From: Iván Brencsics [[email protected]] > > Sent: 26 May 2013 00:48 > > To: [email protected] > > Subject: WS-Trust token handling > > > > Hello, > > > > I need to design a distributed software architecture that implements SSO > > with WS-Trust/SAML. I have made some experiments, read the excellent > blogs > > of the Talend colleagues, and now I have an idea how WS-Trust is working. > > > > I would just have three questions: > > > > 1) In my architecture, there are many components that call each other via > > SOAP. The idea is that when the first component is triggered, it > acquires a > > SAML token from the STS, and then during the subsequent calls this single > > token is used until the workflow is completed. So lets say 1) the module > no > > 1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4) > when > > module no 2 calls module no 3, the same SAML token is transmitted. Is > this > > possible with the CXF implementation? > > > > 2) I need to put claims in the token (eg roles). I saw in a blog how to > do > > that. But on the receiving side, what is the best way to evaluate the > > claims found in the received token? For instance, how to retrieve the > role > > claims? Should I implement some interceptor for that? > > > > 3) I would prefer using SOAP over JMS. Is every WS-Trust operation > working > > over JMS the same way as over HTTP? > > > > Thank you in advance. > > > > Kind regards, > > Ivan > > >
