Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
178 views

Implementing SSO Using Forgerock OpenAM

The document describes the steps to configure single sign-on between OpenAM as an identity provider and PEGA as a service provider using SAML2. These steps include deploying OpenAM, configuring it as an identity provider with a test realm and self-signed certificate, exporting the IDP metadata, configuring PEGA as a service provider using the imported metadata, and testing SSO login between the applications. Key steps are generating a self-signed certificate for signing, configuring OpenAM as an IDP, importing the certificate into OpenAM, configuring PEGA as an SP to communicate with the IDP, and verifying SSO works.

Uploaded by

Pega Training
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
178 views

Implementing SSO Using Forgerock OpenAM

The document describes the steps to configure single sign-on between OpenAM as an identity provider and PEGA as a service provider using SAML2. These steps include deploying OpenAM, configuring it as an identity provider with a test realm and self-signed certificate, exporting the IDP metadata, configuring PEGA as a service provider using the imported metadata, and testing SSO login between the applications. Key steps are generating a self-signed certificate for signing, configuring OpenAM as an IDP, importing the certificate into OpenAM, configuring PEGA as an SP to communicate with the IDP, and verifying SSO works.

Uploaded by

Pega Training
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

1) Downloaded OpenAM-13.0.0.war file and deployed it in \tomcat\webapps directory.

2) Started the tomcat instance and hit this URL – http://localhost:port/openam13/index.jsp

3) By default, got redirected to configuration page where chose the default configuration
option, then give password for admin access.

4) Logged into OpenAM using amadmin/password provided during configuration. Amadmin is


the default admin user id created for openam.
5) Then created a new Realm – TestRealm (A realm is a virtual Identity Provider (IdP) used to
authenticate a domain. Each realm is mapped to a domain or list of domains)

6) Entered into the newly created Realm overview page and then clicked on “Create SAMLv2
Providers” option. Then selected option to create a new hosted identity provider. (This page
allows you to configure this instance of OpenAM server as an Identity Provider (IDP). You can
provide a Name for the provider, Circle of Trust (COT), its metadata of the provider and
optionally Signing Certificate. A COT is a group of IDPs and Service Providers (SPs) that trust
each other and in effect represents the confines within which all federation communications
are performed. Metadata represents the configuration necessary to execute federation
protocols (eg SAMLv2) as well as the mechanism to communicate this configuration to other
entities (eg SPs) in a COT. We shall generate the metadata if you do not have one. You are
required to pick a realm for this provider if there are more than one realm in the system.
Otherwise, this provider will be configured under the root realm.)
We have created a new self-signed key (alias - newkey) to be used. The default one (alias - test)
provided by openam is expired and so will not work with PEGA. The self-signed key creation is
described in points 8 to 12.

7) Save above IDP configuration and download IDP metadata as follows –

Hit url [ServerURL]/saml2/jsp/exportmetadata.jsp?entityid=[IdPentityID]&realm=/realmname

Where:

[ServerURL] is the full AM/OpenAM server URL, for example,


http://host1.example.com:8080/openam

[IdPentityID] is the name of your IdP entity provider. This may be a name or FQDN such as:
http://idp.example.net:8080/openam.

realmname is the name of the realm in which the IdP entity provider is configured. If the IdP entity is
configured in the top level realm (/), you can exclude the &realm parameter.

In my case, this is the URL –

http://localhost:9090/openam13/saml2/jsp/exportmetadata.jsp?entityid=http://localhost:9090/
openam13&realm=/TestRealm

on browser, IDP metadata xml will be displayed and download it as xml file.

8) Request/Response signing –

That may be just a bit of a miswording in the documentation, it’s more like:
“It controls request/response signing requirements” (from either SP/IdP side).

In the hosted SP configuration the setting is to control whether the outgoing Authentication
Requests should be signed, whilst in a hosted IdP’s remote SP configuration it would tell the IdP
whether the Authentication Request MUST be signed.

So to be clear:

to ensure that the Authentication Request is signed, you should set that setting in the hosted SP
configuration.

9) A Java Keystore is a container for authorization certificates or public key certificates, and is
often used by Java-based applications for encryption, authentication, and serving over
HTTPS. Its entries are protected by a keystore password.

10) Generating self-signed private key –


keytool -genkeypair -alias newkey -keyalg RSA -keysize 1024 -validity 730 -
storetype JKS -keystore keystore.jks

View information about keystore file –


11) Steps to configure SSO admin tools –

Download SSOAdmintool13.zip. unzip it and run setup batch file.

12) Importing the self-signed key in openam–


After OpenAM installation, a default keystore is available in a subdirectory of the configuration
directory, such as $HOME/openam/openam/keystore.jks. Its password, stored in
$HOME/openam/openam/.storepass, is changeit by default. The only key in this keystore is for a
self-signed certificate (alias: test). Its password, stored in $HOME/openam/openam/.keypass file.

Make backup copies of the $HOME/openam/openam/keystore.jks,


$HOME/openam/openam/.storepass, and $HOME/openam/openam/.keypass files.

Copy the new keystore.jks file that contains the self-signed key to the $HOME/openam/openam/
folder so that the existing one gets overwritten.

Copy .storepass and .keypass files to the bin folder where sso admin tools are installed and open the,
using notepad and put the new password in plain text. Then run below commands on the .storepass
and .keypass files to encrypt the plain text password put there –

(you need to go to the SSO admin tools bin folder which contains the ampassword batch file) –
D:/Pega/OpenAM-13.0.0/openam/SSOAdmintools-13.0.0/openam13/bin/ampassword -e .keypass

D:/Pega/OpenAM-13.0.0/openam/SSOAdmintools-13.0.0/openam13/bin/ampassword -e .storepass

Above commands will display the encrypted password directly on command prompt screen. Copy
the encrypted value to .keypass and .storepass files and save the files.

Now the self-signed key will be visible in signing key option while configuring IDP provider.

13) Import IDP into PEGA–

Used OOTB “SAMLAuth2 /prweb/sso2” Autentication service –


Click on import idp metadata and give reference to idpmetadata.xml file. All values in authentication
service will be automatically populated from metadata file.

In this particular configuration, “Disable signing request” option is enabled as we have not
configured “Signing Certificate” and “Decryption Certificate” for SP settings (will try it in next
configuration). Now save the Authentication service rule and download the Service Provider
metadata.
14) In this configuration, following attribute mapping is done –

15) A new operator id (SaikatSSO) is created in PEGA with external authentication option
enabled.
16) Now, upload SP metadata in OpeanAM server from below option –
Click on configure to save the settings.

17) Create “SaikatSSO” user id in OpenAM server from “Subject” option–

18) Restart OpenAM server. Hit PRPC url – http://localhost:8080/prweb/sso2. You will
automatically get redirected to OpenAM login screen. Enter userid/password credentials
configured in OpenAM server and on successful authentication, you will be logged into
PEGA.
Configuring Authentication service by selecting the Signing key option inside PEGA –

a) Created a self-signed private key for use in PEGA –

b) Create a new keystore data instance and uploaded the newly created PRPCKeyStore.jks file.
C) Used the same keystore reference for both Signing certificate and decryption certificate.

D) Save changes and download SP metadata. Upload the metadata at IDP. Restart IDP server and hit
PEGA SSO URL.

You might also like