PingFederate: OAuth implementation approaches

Hello IAM Learners

It is common to use claims based authentication in recent times for any SSO integrations using OAuth/OpenID connect standards. 

For OAuth implementation in PingFederate, you could create multiple Access Token Manager and map it to adapter if you have multiple HTML adapters in the deployment, otherwise if you just single HTML Adapter used by all OAuth applications then you don't need any of these I am referring to below.

OAuth request coming from Application can be intercepted and processed in PingFederate using two approaches; OAuthSelector or HTTP Header selector. Both of these approaches requires to use Ping authentication policies.

OAuth Client Set Authentication Selector: All OAuth client IDs should be added in this selector as Client.   

HTTP Request Parameter Name: All OAuth client IDs should be added in this selector as parameter values.

There is another selector OAuth Scope Authentication Selector that will be used for OAuth implementations if you have a requirement to trigger the authentication flow based on client scope. 

 

Identifier First Adapter: PingFederate

Hello IAM Experts

Today, I would like to talk about Identifier First Adapter and how it can be addressed for variety of use cases.

Identifier First Adapter is available out-of-the-box in PingFederate 9.3 version and above. This adapter uses HTML template in the back-end which can be customized as per Org needs and it captures the user identifier (could be email or userid) and it uses two attributes Subject and Domain. 

Domain is typically the user email address. Additional attributes can be added to this adapter as needed. 

Some of the use cases:

1. This adapter can be used if the organization has a requirement to display separate branded login page based on email address or user domain.  
2. This adapter can be used if you need to separate the authentication flow or trigger additional security mechanism based on userid or email address. 

HTML template also uses velocity template which can be customized with HTML/JS as per Org needs. 

PingFederate redirect URL after logout

Readers

Logout is a typical requirement in Single Sign-On world. In the interest of today's post, PingFederate can perform SAML single logout or individual adapter logout and I will talk about these topics in detail in separate post.

It is also a common requirement to be able to redirect user to login page post logout. Today, I will explain the PingFederate capabilities to redirect user to different url post SAML logout.

PingFederate SAML logout end-point is https://<>/startSLO.ping, and this URL will perform SAML single logout. 

TargetResource parameter should be appended to logout URL to redirect the user to login page or to land onto different page.

https://<>/idp/startSLO.ping?TargetResource=https://<> 

This TargetResource should be whitelisted as shown below. 

Add the new <> under Security -> Redirect Validation section by specifying the domain name as abc.domain.com and select TargetResource for SLO and Other checkbox. This setting should be added only when ENABLE TARGETRESOURCE VALIDATION check box is enabled for SLO AND OTHER OPTION.


Without whitelisting the redirect URL, you will see below error 

Tomcat "Cannot recover key" SSL error

Tomcat has been enabled with SSL port. While renewing the SSL certificate, Tomcat server is throwing below error.

java.io.IOException: Cannot recover key
        at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:507)
        at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:218)
        at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:400)
        at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:650)
        at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:434)
        at org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
        at org.apache.catalina.connector.Connector.initInternal(Connector.java:978)
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
        at org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
        at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:821)
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
        at org.apache.catalina.startup.Catalina.load(Catalina.java:642)
        at org.apache.catalina.startup.Catalina.load(Catalina.java:667)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

The error indicates that key can't be recovered using the password specified in server.xml. SSL section in server.xml is as shown below. If you have wallet pfx/p12 file, then you may convert it to java keystore using the same wallet password to use for java keystore password. 

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"  maxThreads="100" SSLEnabled="true" scheme="https" secure="true"            keystoreFile="/u01/app.jks" keystorePass="XXXXX"  clientAuth="false" SSLProtocol="TLS" sslEnabledProtocols="TLSv1.2" />

The keystorePass value is different from passphrase used while creating private key/cert. After recreating the java keystore with same password as key and updated server.xml with new password and Tomcat started working fine. 

Azure AD SAML Integration issue with PingFederate : AADSTS75011

Readers, I'm back!

I would like to resume blogging my working experiences and best possible solutions on technologies that I come across every day.

Today, I would like to share some limitation that I came across on Azure AD SAML integration.

Scenario:

A cloud application is integrated with PingFederate where Ping is IDP and app is SP.
PingFederate is delegating authentication to Azure AD; so Ping is SP and Azure AD is IDP.

Issue:
As per the scenario, all three systems Application, PingFederate and Azure AD are configured with SAML integration.

When Application is accessed, it is throwing an error when it is landing on Azure AD for authentication.

Cause:
As per Azure error code AADSTS75011, the problem seems to be Authentication Context parameter sent by the Application in SAML Authentication request as shown below.

<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>

Refer this article, https://techcommunity.microsoft.com/t5/azure-active-directory/aadsts75011-by-which-the-user-authenticated-with-the-service/m-p/196130#

Azure AD supports only urn:oasis:names:tc:SAML:2.0:ac:classes:Password as authentication context value in SAML requests. Refer this article, https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol

Fix:
Ensure that application would send AuthnContextClassRef parameter as urn:oasis:names:tc:SAML:2.0:ac:classes:Password

Best practices for Oracle Access Manager deployment

Readers,

It is very important to follow best practices for OAM deployment for either single DC setup, or MDC setup or HA functionality etc., Some of the best practices are mentioned below and I will keep updating this post based on comments/feedback.

1. Verify the certification matrix for OAM deployment before beginning installation.
2. Use the latest Java, WebLogic Servers based on certification matrix.
3. Use the same path for Weblogic Home, Oracle Home and Oracle Common Home across environments.
4. For WebServers, use environment specific instance names rather than default names. For eg., while installing and configuring OHS instances, the default instance name is ohs1. It is suggested to use name denoting environment name and server name such as DEV_OHS1 or PROD_OHS1. 
5. For WebServers in HA, if you are installing OHS on multiple boxes then it is suggested to use different OHS instance names. For eg., PROD_OHS1 (on 1st box), PROD_OHS2 (on 2nd box). This will help associating OHS instances with unique instance names in EM console for monitoring purpose. 
6. Ensure that Non-Prod (or QA) and Prod environments identical for all IAM components in order to reproduce Production issues and make future deployments easier and better for operations.
7. Ensure to configure OMSM, Policy Manager and OAM servers in different clusters during initial WebLogic domain configuration.
8. Use load balancers for backend LDAP servers for user store. 
9. Use custom authentication plugins only as per needs. Custom Plugins have maintenance nightmares for Ops team. 
10. Schedule regular backups for oam-config.xml, policy exports and partners export along with DB backups.
11. While configuring user store, specify Referral policy as FOLLOW. Also, specify Min/Max pool size and timeout parameters as per load testing results. 
12. Selectively configure required audit events only.  
13. Avoid creating sample cgi or server side pages that would print headers information. For eg., cgi-bin/printenv script is a common script that's protected through OAM for validation purpose. After Production go-live, remove those test pages. 
14. Exclude images, css files and other static contents in policies instead of using Unprotected policies. 
15. Try to update WebLogic CPU patches and JDK CPU patches based on sensitivity of the fixes. Thorough testing is required before pushing these patches to Production. Sometimes these patches may break OAM functionality. 
16. Use similar RCU versions across environments.
17. Use certain security headers X-XSS-Protection, Strict-Transport-Security etc., in Login WebGate WebServers for better protection. 
18. Use Log rotation for OAM and other WebLogic servers to prevent complete disk usage. 
19. Ensure that only required firewall ports are opened to and from OAM servers instead of opening it through entire subnets. This is to provide better security.
20. Use WebGate CERT mode only if needed otherwise it will degrade performance. 
21. Use SSL at Node Manager and WebLogic Servers are only as needed. 
22. Ensure that Login WebGate has SSL enabled.
23. Ensure that 3rd party cert is used for OAM deployment in Prod and non-prod environments. 
24. Do periodic rolling restarts of OAM server for better system performance.
25. Associate OHS and OAM components with EM 12c for performance and system alerts.
26. Use Min / Max Heap size for OAM tuning. 
27. Use appropriate number of processes, sessions etc., parameters in OAM DB schema.
28. If there are more IAM components in the architecture, it is suggested to use separate DB for OAM component since OAM uses APS for MDC synchronization where as other products requires DG or GG.
29. Ensure to grant admin privileges to LDAP users for OAM console instead of giving generic administrative access to all users.  

 That's it for today. Happy reading!! 

Enabling Multi factor Options for application in Okta

Okta is a simple product to use and it is capable of integrating with more than 5800 applications for Single Sign-On purposes with added security benefits.

In this post I would like to quickly talk about enabling Multi Factor capabilities for an application that is already integrated into Okta. In this case, SalesForce is integrated with Okta using SAML 2.0 protocol.

Follow the below steps to enable MFA capabilities for salesforce application (or this would apply for any other application)

1. Login to Okta Admin Console as admin user.
2. Goto Applications.
3. Goto Sign On Policy section.
   
4. Click Add Rule.
5. Specify Rule Name, Conditions (users /group rule assignment), Location . 
   
6. Specify Actions. Select the option to allow or deny the access after conditions are met. For this exercise I would choose Allow. Select MFA frequency such as prompting MFA every login or once a day etc.,
7. Click on Multifactor Settings.
   
8. Select the desired authenticators. 
   
9. Click Save. 

Now the desired configuration changes are completed. It is time to test. 

1. Login to Okta application console. 
2. Click on SalesForce application.
   
3. User is redirected to MFA page for setup (if its already setup, this page is not seen). In this case, I have selected Google Authenticator setup. Click Setup.
   
4. Select device Type. Install app on mobile device. Click Next.
   
5. Specify the code generated on mobile device here. Click Verify.
   
6. User is redirected to salesforce application.