Best Practices for Managing OneLogin SAML Signing Certificates

As an Identity and Access Management (IAM) solution, one of the core authentication standards that we support is Security Access Markup Language (SAML). You can find out more about how SAML works on our IAM 101 SAML page. When configuring SAML, a trust relationship has to be established between the system that is doing the authentication, known as the identity provider (IdP) and the application the user is trying to get into, known as the service provider (SP). A signing certificate is necessary to establish this trust relationship and is used by the IdP to confirm that the authentication requests are coming from the IdP and not an entity that is trying to trick their way in.

Our customers often ask us about how to manage these signing certificates in terms of the best options to choose when creating them and how to handle renewing them when they expire. Since OneLogin can play both the role of an IdP and of an SP, we have summarized our recommendations for both scenarios.

OneLogin as an Identity Provider

When configuring SAML between an IdP like OneLogin and an SP, an application like Salesforce or Slack, one of the key components that needs to be set up between the IdP and the SP is a signing certificate. This certificate is used by the SP to confirm that the authentication response is coming from the IdP and not from another source pretending to be the IdP and trying to sneak their way in.

Since this is a key part of your authentication, we have gathered together a list of best practices when it comes to configuring and maintaining these SAML Signing Certificates.

Create new signing certificates. The default approach is that ALL SAML apps use the same certificate to verify the authenticity of the handshake process between the IdP (OneLogin in this case) and the SP (whichever application you are configuring OneLogin to authenticate to).

1. Create new signing certificates. The default approach is that ALL SAML apps use the same certificate to verify the authenticity of the handshake process between the IdP (OneLogin in this case) and the SP (whichever application you are configuring OneLogin to authenticate to).
   1. We recommend you create new certificates within OneLogin with the following guidelines in mind:
      1. Deploy a unique signing certificate per SAML application. This would be recommended for high-security environments.
         OR
      2. Assign the same signing certificate to only a limited subset of applications (based on time period). Ergo, create a new default signing cert per year or per quarter such that new federations will use the new cert. In that way, certificate rotations can be managed more easily.
         OR
      3. Assign the same signing certificate to only a limited subset of applications (based on app classification – critical, high, medium & low)
   2. Use a naming convention for the certificates that guides you to where it should be used. For example, “High Security Cert” should tell you that a certificate should be used for those applications that require higher security standards.
   3. Set the most commonly used certificate as the default.
   4. Use expiration periods that are less than 5 years and SHA-256 Signature Algorithms and longest key length supported by applications for the new certificates you create. The more critical the app the shorter the expiration time should be. Make sure that your application supports SHA-256. Make sure that the application you are connecting to supports SHA-256 first. If the application does not then you will have to use SHA-128.
   5. Manage your certificates as you manage other recurring tasks such as upgrades. Ensure to add your OneLogin certificate references to your inventory. This will help you be aware of the certificates deployed and when they expire. You should also include notes on who owns the target application, any special credentials that might be needed and what the process is for updating the certificate at the SP. Some applications can handle this very quickly, while others might require you to submit a support ticket and take days to complete.
      You can create certificates by navigating to the Security menu.
      1. Click Certificates.
      2. Click New in the upper right corner.
2. Change the SAML connector to use SHA-256 SAML Signature Algorithm. This signature is used to verify that the SAML assertion is being sent from the IdP the trust relationship has been set up with. It is important to set the signature algorithm of this cert to SHA-256 as well. The default is SHA-1.

   It will also be necessary to update the certificate that is copied over to the SP every time the IdP certificate is changed. You will want to make sure that you have it in your calendar so that you can proactively create a new certificate at the Settings Certificate level, associate the new certificate with the appropriate app connectors and copy the new certificate generated at the app connector level over to the application itself. If a certificate expires before you are able to create a new one and associate it with the app connector your users might no longer be able to log into that application.

   You can manage these changes on the SSO tab of the application or SP you are configuring.

   

3. Ensure Account Owner email address is monitored such that default certificate expiry notifications are received and acted upon. The “user” used to set up the Account Owner might not be an actual person but more of a service account. It is important, however, that the email address used for this account is real, and there are people who will receive the emails sent to it.
4. Least privilege access should be applied wherever possible. Although it is not possible to extract the private signing key from a OneLogin tenant you should ensure limited and secure access to the OneLogin Administration Portal, Notifications and SIEM Event listeners.
   1. Secure access to the OneLogin Administration Portal
      1. All user accounts that have access to the Administration Portal should be required to use multi-factor authentication (MFA).
      2. Disable Assume User access. This setting is enabled by default and can be disabled globally through Settings Account Settings or on a per application basis from the Access tab.
   2. Use Notifications to alert administrators when sensitive actions occur. Notifications can be used to send emails to administrators (i.e. SuperUsers) when apps are created or updated or someone has assumed access as another user. You can create notifications by going to Activity Notifications.
   3. Use Security Information and Event Management (SIEM) or API-based event extraction). Use a third-party service to gather sensitive action events and display in dashboards as well as send email/sms or other notifications. If somehow an intruder is able to access your OneLogin account with elevated privileges, they could disable notifications within OneLogin to try to conceal their nefarious activities. However, if you use an external event monitoring system, the intruder would not be able to disable the notifications managed by that system. Any attempt by the intruder to disable events from being sent to the external monitoring system will raise flags as well.

OneLogin as a Service Provider

In some cases, OneLogin itself can be configured as a Service Provider (SP) vs as an Identity Provider (IdP). This means that users are in fact being authenticated by another system such as Google to access OneLogin. This is configured using OneLogin’s Trusted Identity Provider (TIdP) feature.

When configuring a OneLogin Account as an IdP, the focus should be on validating responses and protecting OneLogin Admin access.

1. Whenever possible, use the allowed “Email Domains” setting. If an IdP exclusively uses known email domains, then it is recommended to use the allowed “Email Domains” setting to restrict the domains that the IdP can assert. You can find this setting on the Settings tab of your TIdP configuration page.
2. Use MFA. Consider enforcing step-up MFA when consuming an identity from a third-party trust relationship. This would be done by modifying the User Policy applied to the users in question. There is a setting called “Users without a MFA device must register one before being able to login” on the MFA tab of the User Policy that can be selected to ensure that users use MFA in order to login the first time.
3. Use SIEM (or API-based event extraction). As, when acting as an IdP, ensure external event monitoring (SIEM) is in place to capture and alert upon sensitive changes to Trusted IdP configurations – in particular, the addition of new TIdPs which is indicated by event ID 74 being raised.

The following table lists the event IDs that are related to TIDP activity:

It is often difficult to understand which option is best to choose for your environment. Very rarely do we find a one-size-fits-all solution. These best practices are here to help you make the decisions that will work best for your organization.

The One Identity Unified Identity and Security solutions help customers strengthen their overall cybersecurity posture and protect the people, applications and data essential to business. Trusted and proven on a global scale, One Identity manages over 500 million identities for more than 11,000 organizations worldwide. For more information visit www.oneidentity.com.