Tuesday, January 20, 2009

SAML 1.1 cert configuration for Post Profile Assertions in AM 7.0 / 7.1

Commands to setup SAML 1.1 in cert mode in a simple way so that POST profile assertions work.

1) Generated a key using command
/usr/jdk/entsys-j2se/bin/keytool -genkey -keyalg rsa -alias test -dname
"cn=samlsource,ou=SUN Java System Access Manager,o=Sun,c=US" -keypass
11111111 -keystore /etc/opt/SUNWam/config/keystore.jks -storepass
11111111 -validity 180

2) ftp keystore.jks to SP provided you do not need to setup different certs for IdP and SP.

3) For IdP, do
/opt/SUNWam/bin/ampassword -e 11111111 >
/etc/opt/SUNWam/config/.storepass

4) For IdP, do
/opt/SUNWam/bin/ampassword -e 11111111 > /etc/opt/SUNWam/config/.keypass

5) Edit AMConfig.properties in IdP
a) com.sun.identity.saml.xmlsig.certalias=test
b) com.sun.identity.saml.xmlsig.storepass=/etc/opt/SUNWam/config/.storepass
c) com.sun.identity.saml.xmlsig.keypass=/etc/opt/SUNWam/config/.keypass

6) For SP, do
/opt/SUNWam/bin/ampassword -e 11111111 >
/etc/opt/SUNWam/config/.storepass

7) For SP, do
/opt/SUNWam/bin/ampassword -e 11111111 > /etc/opt/SUNWam/config/.keypass

8) Edit AMConfig.properties in SP
a) com.sun.identity.saml.xmlsig.certalias=test
b) com.sun.identity.saml.xmlsig.storepass=/etc/opt/SUNWam/config/.storepass
c) com.sun.identity.saml.xmlsig.keypass=/etc/opt/SUNWam/config/.keypass

9) If any other algo other than dsa is used to generate key, make sure it is correct in /opt/SUNWam/locale/amSAML.properties. Change algorithm name from
xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#dsa-sha1 - to -
xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1

10) Restart AM.


To verify that the cert indeed got generated properly, do
/usr/jdk/entsys-j2se/bin/keytool -list -v -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111


******* Basic Keytool commands - Not needed to quickly configure AM as above ********

# use keytool to setup keystore for xmlsig required by SAML postprofile
sample one can use the same keystore.kjs for different servers, just may need
to regenerated the keypass and storepass with 11111111

com.sun.identity.saml.xmlsig.certalias=test
com.sun.identity.saml.xmlsig.keystore=/etc/opt/SUNWam/config/keystore.jks

/usr/jdk/entsys-j2se/bin/keytool -genkey -keyalg dsa -alias test -dname
"cn=samlsource,ou=SUN Java System Access Manager,o=Sun,c=US" -keypass
11111111 -keystore /etc/opt/SUNWam/config/keystore.jks -storepass
11111111 -validity 180

/usr/jdk/entsys-j2se/bin/keytool -certreq -alias test -file request.csr
-keypass 11111111 -keystore /etc/opt/SUNWam/config/keystore.jks
-storepass 11111111 -storetype JKS

# to generate self-signed cert
/usr/jdk/entsys-j2se/bin/keytool -selfcert -alias test -dname "cn=samlsource,ou=SUN Java System Access Manager,o=Sun,c=US" -keypass 11111111 -keystore /etc/opt/SUNWam/config/keystore.jks -storepass 11111111

# submit the content of request.csr to CA Server. Let us call this approved cert as mycert.cer and root CA as myroot.cer

# install root CA
/usr/jdk/entsys-j2se/bin/keytool -import -file
/home/gc111264/ps/keep/myroot.cer -keypass 11111111 -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111

# install mycert.cer
/usr/jdk/entsys-j2se/bin/keytool -import -alias test -trustcacerts -file
mycert.cer -keypass 11111111 -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111

# print a cert
/usr/jdk/entsys-j2se/bin/keytool -printcert -file "mycert.cer"

# list an alias
/usr/jdk/entsys-j2se/bin/keytool -list -alias test -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111

# list all certs
/usr/jdk/entsys-j2se/bin/keytool -list -v -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111

Generating a self-signed certificate

A self-signed certificate is one for which the issuer (signer) is the same as the subject (the entity whose public key is being authenticated by the certificate). Whenever the -genkey command is called to generate a new public/private key pair, it also wraps the public key into a self-signed certificate.

You may occasionally wish to generate a new self-signed certificate. For example, you may want to use the same key pair under a different identity (distinguished name). For example, suppose you change departments. You can then:

1. copy (clone) the original key entry. See -keyclone.

2. generate a new self-signed certificate for the cloned entry, using your new distinguished name. See below.

3. generate a Certificate Signing Requests for the cloned entry, and import the reply certificate or certificate chain. See the -certreq and -import commands.

4. delete the original (now obsolete) entry. See -delete.

To generate a self-signed certificate, use the -selfcert command, as in

keytool -selfcert -alias dukeNew -keypass b92kqmp
-dname "cn=Duke Smith, ou=Purchasing, o=BlueSoft, c=US"

The generated certificate is stored as a single-element certificate chain in the keystore entry identified by the specified alias (in this case "dukeNew"), where it replaces the existing certificate chain.

2 comments:

  1. This blog is abosolutely wondeful, i like the new ideas introduced here, it catched my attention since the first time that i saw it. i must to say i usually like the good products specially the ones whic can give a lot of benefits. That is why i am proving
    costa rica investment opportunities

    ReplyDelete
  2. ldap online training| ldap training| call us+919000444287 ...
    www.21cssindia.com/courses/ldap-online-training-103.html
    LDAP Online Training, LDAP training, LDAP course contents, LDAP , call us: +919000444287,dharani@21cssindia.com.

    ReplyDelete