How it works?
With reference to the above image, the following are the steps involved in distributed Open ID authentication.
1. The user enters the User Supplied Open ID identifier at the RP web page.
2. Then the User Supplied Open ID Identifier is normalized into a Claimed Identifier (Transforming the User Supplied Identifier into a “standard” form) at the RP web page before sending it to the OP.
3. The Client Browser now Redirected to the OP, depending on the Claimed Identifier. This process is called the “Discovery process” in the Open ID specification. Now the User is required to enter his OP user name and password.
4. If the user is successfully authenticated by the OP, it directs the user browser a to a location (Return URL) specified by the RP. Once the response is sent back, the response is tagging along some attributes of the authenticated user. (i.e Date Of Birth, Postal Code, Country, etc) Otherwise, it will return an unauthenticated message to RP.
How to Test this cycle?
In order to test this cycle, the following two key steps you need to follow:
1. Register with an OP (Open ID Provider): There are plenty of Open ID Providers in the market. (i.e. myOpenId, Verisign, etc)
2. Create a Relying Party (web site): This can be done by leveraging free open source libraries which are available on the web. One of the popular ones is “OpenId for Java” .
There are few sites, which you can make use of “openid4java” libraries.
1. OpenID for Java Applications Part 01 – http://www.ibm.com/developerworks/library/j-openid/
2. OpenID 2.0 Specification – http://openid.net/specs/openid-authentication-2_0.html
3. openid4java – http://code.google.com/p/openid4java/
A Public Key Infrastructure (PKI) is a set of policies and procedures, which are there to manage (issue, renew, revoke, publish) certificates. Any PKI is basically governed by two basic documents.
1. Certificate Practice Statement (CPS)
2. Certificate Policy (CP)
Both these documents are based on internationally recognized RFC 3647 Internet standard. Basically CP defines generic certificate policies and procedures for a given PKI. If a PKI has more than one CA, then all these CAs should follow one single CP. But each of these CAs should have a customized CPS, detailing each CAs customized features.
. RFC 3647 Standard – http://www.ietf.org/rfc/rfc3647.txt
In addition to the “Certificate Issuance”, “Certificate Revocation” can be considered as a very important task of any Certification Authority (CA). The “Certificate Revocations” are primarily handled via “Certificate Revocation Lists”.
There are two ways to maintain the latest “Certificate Revocation Lists”.
1. CRL (Certification Authority List)
2. OCSP(Online Certificate Status Protocol)
CRL is the former and the inefficient approach. Comparatively, the OCSP is the latest and the efficient approach. The main reason for this has been the performance bottlenecks revolved with the CRL approach.
In both approaches, the CA needs to publish a separate Certificate Revocation List in one of their back end servers. These needs to be updated regularly in order to maintain a proper certificate revocation list among its user base.
In the CRL approach, the client (i.e browser) needs to download the complete CRL to the client, every time when there is a change to the CRL. [The location of the referred CRL is usually given in the CRL Distribution Point (CDP) extension of the certificate. These locations are normally either HTTP or LDAP locations.] The downside of this approach is, when the CRL is grown to a large size, downloading the CRL to their respective clients (browsers) can create serious bandwidth issues.
The OCSP enables applications to determine the revocation state of an identified certificate. OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an “OCSP Responder” and suspends acceptance of the certificate in question until the responder provides a response with the good / revoked/ unknown status.
OCSP, mainly consists of a “OCSP Client” and a “OCSP Responder”. OCSP Client is basically the client (browser) and the OCSP Respondent is basically a web service, which has the ability to respond the status of any certificate. The OCSP Client only sends the serial number of the relevant certificate and the response will send back the status of it. If you require further details about OCSP, you may visit RFC 2560 reference .
By having a this kind of an approach, OCSP is able to address the scalability issues inherent in large scale (high volume) Public Key Infrastructure (PKI) environments that require a lightweight solution to minimize communication bandwidth and client-side processing.
Nowadays, all the popular browsers, support both of these approaches and some default their settings to OCSP as well. If you have not come across this so far, it is always good to check the revocation approach of your favorite browser.
2. RFC 2560 – http://tools.ietf.org/html/rfc2560
WS-Security, WS-SecurityPolicy and WS-Trust are three specifications that are very important and heavily consumed in the WS* world of specifications. Though they relate to each other, they are mutually exclusive and it is very much important to understand the boundaries clearly to grasp their key usage. The reference  shows us a very concise definition, out of all the definitions on the web. In fact, this particular article goes on to explain the relationship with WS-Federation as well.
- WS-Security provides a core function by defining mechanisms for assuring message authenticity, integrity and confidentiality through the use of security tokens.
- WS-SecurityPolicy enables the description of the security requirements of services via assertions about the security mechanisms of the services (i.e. algorithms, security tokens). Using these assertions web services are able to recognize and assess the types of security tokens and claims that are required for exchanging messages securely.
- WS-Trust provides an additional piece of the foundation for identity federation by defining a “service model” (This was clearly discussed in my previous blog article), the Security Token Service (STS), and a protocol for requesting/issuing these security tokens which are used by WS-Security and described by WS-SecurityPolicy.
2. SOA Programming Model for implementing Web Services, Part 7 – Securing Service Oriented Applications : http://www.ibm.com/developerworks/library/ws-soa-progmodel7/
In large enterprises, we find different types of Public Key Infrastructures (PKI) inter-operating each other. They may follow the same token profiles within their own infrastructures but they may be different in how the “Trust” is maintained. This is where the PKI “Trust Models” are taken into consideration.
Basically there are two types of PKI Trust Models in the enterprise.
1. Rooted Hierarchical Trust Model.
2. Network (Cross Certification) Trust Model.
Both these hierarchies are maintaining a “chain of certificates” and has the “parent-child relationship” maintained between all certificates in the chain. However, as mentioned the different lies how the chains of certificates are constructed in each model.
Rooted Hierarchical Trust Model
The Root CAs, which are at the top of the hierarchies are self-certified by using a self-signed CA certificate. They are the most trusted CAs in any certificate hierarchy and they need to be highly secured as well. Usually the Root CA private key is physically secured in a safe location and electronically disconnected to any other electronic system mainly to ensure the fullest security. Hence, the subordinate certificate issuance happens through a separate CA (generally known as a “Working CA”), which is basically signed by the Root certificate. This signing basically done off-line and it is called the “Root Key Ceremony”. Thereafter, the Root CA can be only accessed by some appointed individuals in an organization.
The subordinate CAs (intermediate CAs and Issuing CAs) are certified by the parent CAs. The parent CAs are usually an intermediate CA or a Root CA. An intermediate CA issues certificates only to subordinate CAs and Issuing CAs issue certificate to the requested party (users, services, etc). There is no restriction with regard to how deep the certification hierarchy can be. However, generally, a three-level certification hierarchy (root CA, intermediate CA, and issuing CA) meets most of the requirement.
Network (Cross Certification) Trust Model
In this model, each Root CA can cross certify the other Root CA by just importing the public key certificate of the other Root CA. This relationship can be unidirectional or bidirectional thought the preferred way is bidirectional. If Root CA2 is cross certified by Root CA1, all the clients of the Root CA1 is able to trust CA2.
This type of hierarchical trust model can be implemented to create bridges between separate PKIs without either PKI being directly subordinate to the other. However, the governance of such a model is relatively messier than the “Rooted hierarchical trust model”, which we discussed before.
Hybrid Trust Model?
There is always Pros and Cons of any model to some situations. Some organizations may find the Rooted Trust model too restrictive. Some may find the Network (Cross) Trust model too complex to their likings. Hence, some may want adopt to a model in between of both by having features of both. That is also very much possible.
1. Designing your CA infrastructure – http://technet.microsoft.com/en-us/library/cc728390%28v=ws.10%29.aspx
2. Certification Authority Trust Model – http://technet.microsoft.com/en-us/library/cc962065.aspx
3. Selecting the Trust Model – http://technet.microsoft.com/en-us/library/cc782164%28v=ws.10%29.aspx
Using the keytool utility, it is easy to extract the public key of an already created “public-private” key pair, which is stored in a keystore.
Here are the steps:
Step 1: Creating the “public-private” key-pair.
keytool -genkey -alias certificatekey -keyalg RSA -validity 7 -keystore keystore.jks
Step 2: Validate the “public-private” key pair, which was created under the Step 1.
keytool -list -v -keystore keystore.jks
The output would be like this.
crishantha@crishantha-laptop$ keytool -list -v -keystore keystore.jks Enter keystore password: password Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: certificatekey Creation date: Aug 23, 2011 Entry type: keyEntry Certificate chain length: 1 Certificate: Owner: CN=Crishantha Nanayakkara, OU=Technical, O=ICTA, L=Colombo, ST=Western, C=SL Issuer: CN=Crishantha Nanayakkara, OU=Technical, O=ICTA, L=Colombo, ST=Western, C=SL Serial number: 4e531ddf Valid from: Tue Aug 23 08:56:23 IST 2011 until: Tue Aug 30 08:56:23 IST 2011 Certificate fingerprints: MD5: 4A:40:DB:0B:50:AF:A5:A7:DC:FD:D0:18:1D:5E:DC:BB SHA1: 0A:BF:07:1A:4B:D2:A8:4B:35:3E:4B:B9:60:D7:E9:22:02:F0:04:FF ******************************************* *******************************************
Step 3: Extract the “public key” from the “public-private” key pair that you creates under the Step 1.
keytool -export -alias certificatekey -keystore keystore.jks -rfc -file public.cert
Step 4: Check the extracted public key (public.cert)
The output would be like this.
-----BEGIN CERTIFICATE----- MIICXDCCAcUCBE5THd8wDQYJKoZIhvcNAQEEBQAwdTELMAkGA1UEBhMCU0wxEDAOBgNVBAgTB1dl c3Rlcm4xEDAOBgNVBAcTB0NvbG9tYm8xDTALBgNVBAoTBElDVEExEjAQBgNVBAsTCVRlY2huaWNh bDEfMB0GA1UEAxMWQ3Jpc2hhbnRoYSBOYW5heWFra2FyYTAeFw0xMTA4MjMwMzI2MjNaFw0xMTA4 MzAwMzI2MjNaMHUxCzAJBgNVBAYTAlNMMRAwDgYDVQQIEwdXZXN0ZXJuMRAwDgYDVQQHEwdDb2xv bWJvMQ0wCwYDVQQKEwRJQ1RBMRIwEAYDVQQLEwlUZWNobmljYWwxHzAdBgNVBAMTFkNyaXNoYW50 aGEgTmFuYXlha2thcmEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIX7GylhsLdXUZyUFStm djMUA6L8O6/ykXkbU+c9v6O8/l3HTNtLDmfi5+tbKP1QLCxv1D1b4MlbBol00a4TjpNWqLcni2H9 NUW6sZowRpLusiRUfy0gOwZpAkkNfjnkz41A4sgoM4p4qCV+mreeD1lwHEdBvfUpkKc+sVOn5kD9 AgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAY76IASMj3wjtoqW6MAbIWAmwFM18ANupvbH6k2vMui+O 7O0UXd/1NTuCkP4gowYmbvqW07zt7IAbjrXN841AGlEdEWktwOhZuz6+XknOG1AvGXz57DTdSDo/ OTSz1eDSiBQ0qWjVCsbeM/4jBge6QCWoeoum/L+AIQyHzJ+vUUU= -----END CERTIFICATE-----
Step 5: Now it is the time to create the truststore using the public key, which was extracted at Step 3.
keytool -import -alias certificatekey -file public.cert -keystore server.truststore
Step 6: Congratulations! You have now created a self-signed certificate using the keytool. Now you can validate the contents using the keytool.
keytool -list -v -keystore server.truststore
The output would be like this.
crishantha@crishantha-laptop:~$ keytool -list -v -keystore server.truststore Enter keystore password: password Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: certificatekey Creation date: Aug 28, 2011 Entry type: trustedCertEntry Owner: CN=Crishantha Nanayakkara, OU=Technical, O=ICTA, L=Colombo, ST=Western, C=SL Issuer: CN=Crishantha Nanayakkara, OU=Technical, O=ICTA, L=Colombo, ST=Western, C=SL Serial number: 4e531ddf Valid from: Tue Aug 23 08:56:23 IST 2011 until: Tue Aug 30 08:56:23 IST 2011 Certificate fingerprints: MD5: 4A:40:DB:0B:50:AF:A5:A7:DC:FD:D0:18:1D:5E:DC:BB SHA1: 0A:BF:07:1A:4B:D2:A8:4B:35:3E:4B:B9:60:D7:E9:22:02:F0:04:FF ******************************************* *******************************************
Now if you really notice, while you are listing out the keystore in step 2, the certificate indicate as “keyEntry”. However in Step 6, it is listed as “trustedCertEntry”. The difference is the former had the private key with it and the later did not.
Sometimes, you might need the private key also from the keystore. However, it is not that straight forward as you wish. Unlike exporting the certificate out of the key-pair, you are required to save the private key in the PKCS#12 format and secondly you can convert that to a text file. So, here are the steps:
keytool -v -importkeystore -srckeystore keystore.jks -srcalias certificatekey -destkeystore myp12file.p12 -deststoretype PKCS12
openssl pkcs12 -in myp12file.p12 -out private.pem
Although it is mandatory to go through a recognized CA (Certification Authority) in order to build “trust” between two parties, you definitely can create self-signed certificates in order to test your web application, which uses digital certificates for encryption and signing.
There are mainly two popular tools in the industry to create self-signed certificates.
1. Generating the “private key”. There are two types of private keys. RSA and DSA.
Creating the RSA private key: There is only one step.
openssl genrsa -out crish_private_key.pem 2048
Creating the DSA private key. There are two steps.
openssl dsaparam -out crish_dsa_param.pem 2048
openssl gendsa -out crish_private_key.pem crish_dsa_param.pem
2. Generate the certificate using the generated private key.
openssl req -new -x509 -key crish_private_key.pem -out crish_cert.pem -days 365
3. Convert the certificate to PKCS12 format. (Which is the keystore)
openssl pkcs12 -export -in crish_cert.pem -inkey crish_private_key.pem -out crish_cert.p12
4. Generating the CSR (Certificate Signing Request) when you need a valid CA assurance. You are required to send this CSR file to the selected CA and get a signed certificate.
openssl req -new -key crish_private_key.pem -out crish_certificate_request.csr
1. Generating the key pair into a keystore (JKS)
keytool -genkey -keyalg RSA -keysize 2048 -keystore crish_keystore.jks -alias crish
keytool -genkey -keyalg DSA -keysize 2048 -keystore crish_keystore.jks -alias crish
2. Generating the CSR.
keytool -certreq -alias crish -keystore crish_keystore.jks -file crish_certificate_request.csr
If you compare above methods, it is apparent that KeyTool has got less number of steps than OpenSSL. But, OpenSSL has the ability to import or export private keys using keystores.
How to list a keystore contents?
keytool -list -v -keystore crish_keystore.jks -storepass password
The difference between the keystore and truststore
A keystore contains private keys, and the certificates with their corresponding public keys. You only need this if the server requires the client authentication. A truststore contains certificates of other parties that you expect to communicate with. The keystore and truststore can be the same file. However, it’s usually easier to manage keys if they are separate: the truststore can contain the public certificates of trusted CAs and can be shared easily, while the keystore can contain the private key and certificate of the local server and can be stored in a protected location.
If your server’s certificate is signed by a recognized CA, the default truststore that ships with the JRE will already trust it (because it already trusts trustworthy CAs), so you don’t need to build your own, or to add anything to the one the JRE.
1. Generate RSA key to sign the certificate.
openssl genrsa -out key.pem 2048
2. Generate the certificate using the generated key.
openssl req -new -x509 -key key.pem -out cert.pem -days 365
3. Convert the PEM certificate to PKCS12 format.
openssl pkcs12 -export -in cert.pem -inkey key.pem -out cert.p12
4. Edit the $TOMCAT_HOME/conf/server.xml to modify the SSL connector.
<Connector port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" debug="0" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreType="PKCS12" keystoreFile="conf/cert.p12" keystorePass="password"/>