Implementing Single Sign-On on the Location Risk Intelligence Platform

How it works

Using SSO, a company member can access various applications securely using just one set of credentials. For example, when members of a customer organization sign in to their company's system and use their corporate identity system, they automatically sign in to the Location Risk Intelligence Platform in the background.

The SSO setup has two phases:

1. Setup involves gathering customer requirements, setting up access, testing, and activating SSO. For a detailed information, refer to Implementation phase.
2. Usage involves maintaining the integration, such as exchanging certificates based on the federation method.

Shared responsibility in a federated partnership

We provide a federated SSO upon request, with two distinct roles and responsibilities:

• The identity provider (IDP)—the customer—provides a secure digital token that contains reliable identity information. Customer organizations store users with personal information and designated roles.
• The service provider (SP)—Munich Re Service GmbH—validates the token, sets up a session for the user, and allows access to the application environment.

SSO benefits at a glance

Using single sign-on has the following benefits:

• Improved user experience: With SSO, users only need to sign in once to access multiple services, simplifying the authentication process and eliminating the need to remember multiple credentials.
• Standardized authentication: SSO streamlines access across diverse tools and platforms, making the authentication standard and consistent.
• Enhanced security controls: By centralizing authentication in one app, organizations can secure access across multiple applications, thus improving the security of their apps and data.
• Streamlined identity management: SSO helps administrators keep track of changing permissions and apply access policies and rules across multiple applications using one interface.
• Enhances interoperability: SSO provides a seamless integration between various services, improving interoperability and making it easier to use different tools and platforms.

Supported methods and protocols

We support the following methods and protocols for SSO:

• OAuth 1.0 and OAuth 2.0 is an open standard authorization framework that allows third-party services to access user account information through token-based authorization. It acts as a mediator, providing a secure way for users to share their account information without revealing their credentials. OAuth has two versions—1.0 and 2.0. While OAuth 1.0 was initially created for websites, OAuth 2.0 can be used for both apps and websites. It is faster, easier to set up, and has six possible authorization flows compared to only three in OAuth 1.0. OAuth 2.0 was intended as a radical redesign of the older version.
• SAML (Security Assertion Markup Language) is an enterprise federated authentication protocol that enables single sign-on for users accessing multiple systems with a single ID and password. It securely passes authentication and authorization data between an identity provider (IDP) and a service provider (SP).
• OpenID Connect (OIDC) is an identity authentication protocol, an extension of OAuth 2.0, to verify user identities when accessing digital services. It provides a secure way to use the systems they are trying to access.

Implementation phase

Note: The SSO implementation process takes up to 8 weeks. It involves tasks within our CIAM team and interaction with the customer organization and their IT specialists.

Each phase of the implementation process requires corresponding actions from parties involved.

Claims mapping

In an IDP setup, claims mapping is a critical process that involves converting user attributes from the identity provider into the required format for a service provider or application. This conversion is necessary to ensure smooth integration and access control, particularly when IDP and SP attribute names or formats differ.

Claims mapping rules define how user attributes are transformed for compatibility, and they can be configured within the IDP, SP, or a federated identity service. The process helps to convert user information, such as email addresses and roles, for authorization and personalization purposes. Efficient claims mapping facilitates secure access, consistent user identity management, and effective integration across various systems.

In the kick-off meeting, we also discuss the required claims for the token based on the intake form. The claims may vary depending on the protocol and customer naming conventions.

Role mapping

Role mapping involves converting user roles or group memberships from the identity provider's system to those recognized by the service provider's system. This process is critical for access control, as it determines what resources users can access and what they can do within an application or service based on their roles.

Role mapping ensures seamless integration and interoperability between different systems in a federated identity environment. This mechanism ensures that users have appropriate access based on their roles without manual configuration. Role mapping supports the principle of least privilege, enhances security, and simplifies the user experience with SSO across multiple services.

Here's how roles mapping works in a typical IDP setup process:

1. Identification of user roles in IDP: Users are assigned roles or added to groups based on their job functions or department affiliations within the customer organization. IDP manages there roles or group membership along with the organization's user identities and their associated attributes.
2. Authentication and role claims: When a user attempts to access Location Risk Intelligence, the IDP authenticates their identity and includes claims about the user, including their roles within the application.
3. Roles mapping configuration: To ensure that the service provider understands the user's roles as asserted by the IDP, role mapping configuration is required in our CIAM system. This intermediary service facilitates federation and maps the roles or groups from the IDP to equivalent roles or permissions within the Location Risk Intelligence Platform. 
   For example, an IDP might assert that a user belongs to the "Engineering" group, so the SP must map this user to a role that grants access to specific technical documentation and engineering tools in the target system.
4. Application of mapped roles: After the roles are mapped, the service provider applies the corresponding permissions within the Location Risk Intelligence Platform. This determines what the user can do within the service, such as viewing specific reports or performing certain actions.

In the kick-off meeting, we also discuss the roles required for Location Risk Intelligence. These roles are subject to the intake form.