You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christian Stettler <ch...@innoveo.com> on 2012/01/30 10:41:53 UTC
Explanation of certificates used in Fediz STS / IDP
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
AW: Explanation of certificates used in Fediz STS / IDP
Posted by Oliver Wulff <ow...@talend.com>.
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 [gmazza@talend.com]
Gesendet: Montag, 30. Januar 2012 14:05
Bis: users@cxf.apache.org
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
Re: Explanation of certificates used in Fediz STS / IDP
Posted by Glen Mazza <gm...@talend.com>.
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