Hi Christian When I prepared the Fediz STS [1] and IDP [2] I didn't change the original keystores provided by test cases of the CXF STS. Therefore, there are keys in the keystore which are not required in the IDP/STS case (like myservicekey).
Due to the fact that all the certificates are self signed (not recommended for production) it might confuse even more. Glen described on his blog [3] how to set up the CXF STS using an AsymmetricBinding (which means security on the soap message level and no HTTPS) whereas the sample of the CXF STS described in [1] uses a TransportBinding (only HTTPS). Here we talk about the secure communication between the STS client (IDP) and the STS. It's orthogonal which certificate you use to sign the SAML token in the STS. I'd recommend not to use the same as it's a different certificate usage. You can of course change the policy of the STS in IDP/STS but it has a performance impact. This doesn't impact too much as the web login is done only once. I this case, I prefer the usage of the TransportBinding. As Glen describes in [4], create a self signed certificate for Tomcat (only for testing). You must also configure this keystore (keep in mind this keystore includes the private key ;-) within the STS Client configuration in the IDP (WEB-INF/beans.xml): <http:conduit name="https://localhost:9443/.*";> <http:tlsClientParameters disableCNCheck="true"> <sec:trustManagers> <sec:keyStore type="jks" password="cspass" resource="clientstore.jks"/> </sec:trustManagers> </http:tlsClientParameters> </http:conduit> If you configure a certificate signed by a public CA you only have to configure the keystore which contains the CA certificates. The certificate used to sign the SAML token is configured in (WEB-INF\cxf-transport.xml): <bean class="org.apache.cxf.sts.StaticSTSProperties" id="transportSTSProperties"> <property name="signaturePropertiesFile" value="stsKeystore.properties"/> <property name="signatureUsername" value="mystskey"/> <property name="callbackHandlerClass" value="org.apache.cxf.fediz.service.sts.PasswordCallbackHandler"/> <property name="encryptionPropertiesFile" value="stsKeystore.properties"/> <property name="issuer" value="DoubleItSTSIssuer"/> <property name="encryptionUsername" value="myservicekey"/> </bean> You reference in signaturePropertiesFile a properties file (which configures the keystore, keystore type, ...) and the certificate alias in signatureUsername. The certificate references by signatureUsername is used to sign the SAML token. If you like you can use mutual SSL handshake. This means an additional SSL client certificate which must be configured on the STS client (IDP) side (see <keyManagers> element in tlsClientParameters) and (if self-signed) added to the trust store of the tomcat keystore (server.xml). <http:conduit name="https://localhost:9443/.*";> <http:tlsClientParameters disableCNCheck="true"> <sec:keyManagers keyPassword="password"> <sec:keyStore type="JKS" password="password" file="my/file/dir/Morpit.jks"/> </sec:keyManagers> <sec:trustManagers> <sec:keyStore type="jks" password="cspass" resource="clientstore.jks"/> </sec:trustManagers> </http:tlsClientParameters> </http:conduit> But it should be fine to use one-way SSL handshake here. HTH Oli [1] http://owulff.blogspot.com/2011/10/configure-and-deploy-cxf-25-sts-part-i.html [2] http://owulff.blogspot.com/2011/10/configure-and-deploy-identity-provider.html [3] http://www.jroller.com/gmazza/entry/cxf_sts_tutorial [4] http://www.jroller.com/gmazza/entry/ssl_for_web_services ------ Oliver Wulff http://owulff.blogspot.com Solution Architect Talend Application Integration Division http://www.talend.com ________________________________________ Von: Glen Mazza [[email protected]] Gesendet: Montag, 30. Januar 2012 14:05 Bis: [email protected] Betreff: Re: Explanation of certificates used in Fediz STS / IDP Articles #17 and #18 here: http://www.jroller.com/gmazza/entry/blog_article_index, may give you more background on the purpose of each key. Of course, a key is used whenever an actor needs to sign or encrypt a message, so you'll see it employed in a WS-Trust scenario whenever any actor (client, STS, or WSP) is performing one of those actions, which depends on how you are implementing WS-Trust (e.g., UsernameToken or X509 authentication of the client with the STS, and the signature/encryption requirements of the security token created by the STS). For myservicekey, symmetric binding can be used between the WSP and WSC after the latter has the security token and is ready to make a SOAP call, hence the need for the WSC to have it (to encrypt the SOAP call), and the STS uses the WSP's (public) key for token validation and if the STS needs to encrypt the issued token such that only the WSP can read it. HTH, Glen On 01/30/2012 04:41 AM, Christian Stettler wrote: > Dear list, > > while playing with the Fediz IDP / STS, some questions arose in the context > of certificates used: > > In the sample keystores of IDP (clientstore.jks) and STS (stsstore.jks), > there are a number of certificates included: > > IDP (clientstore.jks) > - mystskey, Feb 9, 2011, trustedCertEntry > - myservicekey, Feb 28, 2011, trustedCertEntry > - myclientkey, Feb 9, 2011, PrivateKeyEntry > > STS (stsstore.jks) > - mystskey, Feb 9, 2011, PrivateKeyEntry > - myservicekey, Feb 9, 2011, trustedCertEntry > - myclientkey, Feb 9, 2011, trustedCertEntry > > We currently have the following understanding: > > - mystskey: private key of the STS, used for signing the requested token > (???), imported into IDP trust store for the SSL connection to the STS (in > case the STS key is used as the SSL certificate) > - myservicekey: purpose unclear > - myclientkey: private key of the IDP, used to authentication against the > STS, if client authentication is enabled > > Is our understanding correct so far? It would be great if someone could shed > some more light on the various certificates involved and their purpose. > > A few other questions in this area: > - is (or should) the IDP use mutual SSL authentication to the STS? > - which certificates need to be known to the Tomcat plugin? The STS > certificate for validating the token? Or is the Tomcat plugin ever connecting > to the IDP issue URL and therefore would also need to have the IDP HTTPS > endpoint certificate in the trust store? > > Thank you& regards, > Christian -- Glen Mazza Talend Community Coders - coders.talend.com blog: www.jroller.com/gmazza
