Introduction : OpenID Connect (OIDC)
Let’s kick things off by quickly understanding what OpenID Connect (OIDC) is:
OpenID Connect (OIDC) is a simple and secure way for apps and websites to confirm who you are—without making you create yet another password. It’s built on top of OAuth 2.0, a widely used standard for secure access. Instead of storing passwords, OIDC lets your app rely on a trusted service (called an Authorization Server) to handle login. When you sign in, the app gets a verified “identity token” and some basic profile details, so it knows who you are.
Why is this great?
Safer: No password storage means fewer chances of data breaches.Convenient: Works across web, mobile, and JavaScript apps.Flexible: Supports extra features like encrypted data and single sign-out.
In short, OIDC answers the question: “Who is using this app right now?”—in a secure, modern way.
So, what is Authorization Server and how it is related to Identity check and Authentication…..
Identity Provider (IdP): This is the service that authenticates the user and provides identity information (claims), in simple terms, Who authenticates the user and provides identity data.. Examples: Azure AD, Okta, Google Identity, SAP Cloud Identity Services.
Authorization Server: This is the component that issues tokens (ID token, access token) as part of the OAuth 2.0/OIDC flow, in simple terms, Who issues tokens and enforces OAuth/OIDC protocol. It handles the authorization and token exchange.
In most implementations, the Identity Provider and Authorization Server are part of the same system. For example: Azure AD acts as both IdP and Authorization Server. Okta does the same.
So, while they play conceptually different roles, in practice, you’ll often configure just one endpoint because the IdP usually includes the Authorization Server functionality.
Following is the simple block diagram explaining the OIDC flow:
Now that we know what OIDC is and why it matters, let’s move on to see how you can configure it in SAP BusinessObjects BI Platform. Starting with BI 4.3 SP02, SAP BusinessObjects BI Platform introduced native support for OpenID Connect (OIDC) authentication. This means BI Launchpad can now leverage modern, secure, and password-free login flows using trusted identity providers like SAP Cloud Identity Services, Azure AD or Google…
Note:
This information in the below sections are applicable for BI 4.3 SP02 and above and BI 2025 versions.For this explanation I have used Azure AD (Microsoft Entra ID) as an Authorization Server / Identity Provider. Otherwise, you can use, any of the Authorization Server / Identity Provider which supports OAuth 2.0 protocol & OIDC.
BI Platform : OIDC Authentication in nutshell
As mentioned in my what’s new blog for BI 4.3 SP02 release, OIDC authentication is introduced along with the OAuth SSO functionality. Let us see, what we need to know about OIDC authentication implementation in BI Platform:
OpenID Connect Authentication is implemented in BI Platform on top of Enterprise Authentication. Works with all the Authorization Server / IDP which support OpenID Connect Authentication based on OAuth 2.0 protocol.Uses the Authorization Server configuration in Central Management Console, this means it uses the configuration stored in the BI Platform backend. User base at your IDP, with which you are planning to use OIDC in BI Platform should have corresponding user accounts in BI Platform as an Enterprise aliases with the same Email (as BI Platform implementation for OIDC is based on email claim only.) which is configured for those users at IDP. Hence, these user accounts in BI platform need to be created in advance. (Please refer point 24 in the Central Management Console configuration section below). OpenID Connect Authentication in BI Platform is only supported for BI Launchpad and OpenDocument client applications.It is mandatory to enable HTTPS for the web applications (BOE & biprws) to configure OAuth SSO and / or OpenID Connect Authentication in BI Platform, as most Authorization Servers or IDPs insist to configure Redirect URI with https (Please refer Point no. 7 in Authorization Server configuration steps section below). Moreover using https is secure way and recommended method for communication over the wire.
BI Platform : OIDC Authentication vs SAML Authentication
As you already aware that BI Platform also supports SAML (Security Assertion Markup Language) based Authentication for web applications like BI Launchpad and CMC, wondering which method is recommended?
As you know, SAML Authentication support in BI Platform exists much earlier, that is from BI 4.2 SP05 release onwards. And it was the de facto choice for many organizations deploying SAP BusinessObjects. As it was better choice that time when compared existing authentication methods, when compared to the basic authentication (password based) in security perspective and to platform native SSO methods (like Windows AD, LDAP or SAP) in complexity and modern protocol perspective.
But now that BI Platform also got OpenID Connect Authentication support, so let us see which is better and recommended choice….
FeatureSAML (Security Assertion Markup Language)OpenID Connect (OIDC)
(Core Function)Authentication & Authorization (XML-based assertions)
Authentication (identity verification)
& Authorization (via OAuth)
(Data Format)XML (Heavyweight, complex)JSON Web Tokens (JWTs) (Lightweight, simple)Protocol StandardsXML StandardsOAuth 2.0 (extension of it)User ExperienceCan be more complex/heavyweight.Simpler, smoother with user-agent redirection (e.g., “Sign in with SSO”).IntegrationCan be complex to implementEasier integrationTransport styleVarious bindings (HTTP Redirect, POST, SOAP)Simple HTTPS flows (HTTP Redirect, POST).
Uses claims carried in JWT and/or returned by UserInfo (scopes map to claim sets).
YesBIP: Works without Trusted Authentication enabled in BI Platform
YesBIP: Native implementation (without using third party software)
YesBIP: Roadmap
Innovations / Improvements are lined up
As you can see with the above comparison, it is evident that OIDC is the better choice when compared to SAML in BI Platform, and also OIDC is recommended as it is the latest and based on modern protocol.
Hope you got the fair Idea about What is OIDC, and how it is implemented in BI Platform, why you can choose to go for it against legacy and SAML Authentication. So, let us move on to configuration part.
Here’s how you can set it up step by step…… Back to top ⮭
Authorization Server : configuration steps
To enable OpenID Connect (OIDC) authentication for any client application, the first step is to register that application (known as the Relying Party—in this case, the BI Platform) with the Authorization Server. This registration ensures that when the client initiates an OpenID Connect request, the OpenID Provider (OP) or Authorization Server can identify and trust the client application. By establishing this trust relationship, the Authorization Server can securely issue tokens and provide user identity information to the registered client.
Sign in to your Authorization Server admin Portal
Here in our example Authorization Server is Microsoft Entra ID, hence, go to https://portal.azure.com.Navigate to Microsoft Entra ID (previously Azure Active Directory).
In Microsoft Entra ID, select App registrations under Manage sectionClick New registrationEnter Name: A descriptive name for your app. for ex: BIPOpenIDAuthselect Supported account types, according to your organizational needsEnter Redirect URI, by selecting the Web as the platform, the following url – https://<biphostname>:<port>/biprws/v1/oauth2/callbackNote: Replace “biphostname” and “port” with your BOBJ web application deployment details.It is mandatory and also the secure way to use https url.Click RegisterAfter registration, note down Application (Client) ID, Directory (tenant) ID, from the Overview section of the registered application.Go to Certificates & Secrets and click on New client secretAdd description and select expiry.Copy the secret value (you will need this along with Client ID for configuration in CMC)Note: The secret value is displayed only once immediately after creation. Make sure to copy and store it securely at that time. Once you leave this page, the secret will no longer be visible and cannot be retrieved later.Under API permissions, ensure openid, profile, email, and User.Read permissions are added from Microsoft Graph API as Delegated permissions by clicking on Add a permission(Optional) Add Files.ReadWrite.All and offiline_access permissions, if in case, if you want to use the same configuration for making Microsoft OneDrive as Scheduling destination as well as use Office documents as data source for Web Intelligence documents.Add any additional permissions your app needs.Grant admin consent if required.
Collect the following details, before proceeding for the next step
Directory (tenant) IDIssuer URL – https://login.microsoftonline.com/{tenant}/v2.0Application (Client) IDClient Secret (secret value)Redirect URL
BI Platform : Central Management Console Configuration
After completing the configuration on the Authorization Server and obtaining the necessary application details, you can proceed to the Central Management Console (CMC) to configure the BI Platform side. As mentioned in the introduction, SAP BusinessObjects BI Platform introduced native support for OpenID Connect (OIDC) starting with BI 4.3 SP02, along with the underlying OAuth SSO feature. I’ve explained OAuth SSO in detail in another blog, where you’ll also learn about a new application called Authorization Server Configuration under the Applications section in CMC. This application serves as the foundation for all OAuth SSO-based functionalities in the BI Platform, including OAuth SSO for databases and OData, OIDC-based authentication, and scheduling to cloud storage services such as Google Drive and Microsoft OneDrive.
launch http://<biphostname>:<port>/BOE/CMC/ and login with Administrator or delegated admin account having privileges to manage ApplicationsNavigate to Applications under Manage sectionRight click on Authorization Server Configuration and select the Authorization Server Configurations option.In Authorization Server Configurations pop up, select New Authorization Server Configuration option from Manage drop down menu.Enter the desired configuration name in the Reference Name text box.(Optional) Enter the relevant description text in the Description text box.If you are using BI 2025 and above, then you will see the option to choose the Grant Type, in that keep the default option Authorization Code.Note:In earlier versions of BI Platform (Prior to BI 2025), this option was not available, and Authorization Code Grant Type was implicit value in those BI Platform versions.Authorization Code flow is most secure and recommended Grant Type for the OIDC Authentication scenario. BI Platform only allows OIDC authentication via the Authorization Code flow grant type only.BI Platform was only supporting Authorization Code flow priori to BI 2025, but from BI 2025 onwards, it supports Authorization Code flow & Client Credentials flow.Authorization Code flow for OIDC & OAuth SSO scenarios.Client Credential flow for OAuth SSO scenarios. (which is meant for server-to-server or machine-to-machine authorization)For more information on Grant Types refer OAuth 2.0 Authorization Framework.Select the checkbox labeled Enabled for “OpenID Connect” Authentication, to indicate the configuration is ready for using the OpenID Connect (OIDC) Authentication.Observe that, Issuer URI, JSON Web Key Sets URI (jwks_uri) and ID Token Signing Algorithm fields gets enabled.Enter the Issuer URI in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/v2.0 (replace tenant value with your tenant identifier)(Optional) Click on Get details button next to Issuer URI text box after entering the correct value.CMC UI has functionality implemented to fetch and fill the values automatically for JSON Web Key Sets URI (jwks_uri), Authorization Endpoint, Token Endpoint.If you do not want use this Get details functionality then you need to fill jwks_uri, authorization endpoint and token endpoint manually.Enter the JSON Web Key Sets URI (jwks_uri) (if not fetched through Get details), in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys (replace tenant value with your tenant identifier)For ID Token Signing Algorithm, BI Platform supports only RS256, hence it is the only value available in the list and selected by default.Enter the Authorization Endpoint (if not fetched through Get details), in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize (replace tenant value with your tenant identifier)Enter the Token Endpoint (if not fetched through Get details), in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token (replace tenant value with your tenant identifier)Note:If in case, your Authorization server, which you are planning to use for configuring OIDC Authentication in BI Platform is capable of and enabled with “OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens” then in the Token Endpoint text box may get filled with the alternative token endpoint than the conventional end point.Because when Mutual TLS Client Authentication and Certificate-Bound Access Tokens functionality enabled at the Authorization server side, then the OpenID Connect discovery will contain the “mtls_endpoint_aliases” JSON object consists of one or more endpoint parameters, such as token_endpoint, revocation_endpoint, introspection_endpoint, etc. For more information on mtls_endpoint_aliases refer RFC 8705.Here is the example for Microsoft Entra Id with common discovery url, where in which you can observe the “mtls_endpoint_aliases” with an alternative token_endpoint along with conventional token_endpoint url… which will be in the following format: https://mtlsauth.microsoft.com/{tenantid}/oauth2/v2.0/token {
“token_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/token”,
“token_endpoint_auth_methods_supported”: [
“client_secret_post”,
“private_key_jwt”,
“client_secret_basic”,
“self_signed_tls_client_auth”
],
“jwks_uri”: “https://login.microsoftonline.com/common/discovery/v2.0/keys”,
“response_modes_supported”: [
“query”,
“fragment”,
“form_post”
],
“subject_types_supported”: [
“pairwise”
],
“id_token_signing_alg_values_supported”: [
“RS256”
],
“response_types_supported”: [
“code”,
“id_token”,
“code id_token”,
“id_token token”
],
“scopes_supported”: [
“openid”,
“profile”,
“email”,
“offline_access”
],
“issuer”: “https://login.microsoftonline.com/{tenantid}/v2.0”,
“request_uri_parameter_supported”: false,
“userinfo_endpoint”: “https://graph.microsoft.com/oidc/userinfo”,
“authorization_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/authorize”,
“device_authorization_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/devicecode”,
“http_logout_supported”: true,
“frontchannel_logout_supported”: true,
“end_session_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/logout”,
“claims_supported”: [
“sub”,
“iss”,
“cloud_instance_name”,
“cloud_instance_host_name”,
“cloud_graph_host_name”,
“msgraph_host”,
“aud”,
“exp”,
“iat”,
“auth_time”,
“acr”,
“nonce”,
“preferred_username”,
“name”,
“tid”,
“ver”,
“at_hash”,
“c_hash”,
“email”
],
“kerberos_endpoint”: “https://login.microsoftonline.com/common/kerberos”,
“mtls_endpoint_aliases”: {
“token_endpoint”: “https://mtlsauth.microsoft.com/common/oauth2/v2.0/token”
},
“tls_client_certificate_bound_access_tokens”: true,
“tenant_region_scope”: null,
“cloud_instance_name”: “microsoftonline.com”,
“cloud_graph_host_name”: “graph.windows.net”,
“msgraph_host”: “graph.microsoft.com”,
“rbac_url”: “https://pas.windows.net”
}As mentioned in the above point, Token Endpoint text box gets filled with this alternative token_endpoint value, due to some issue in parsing the discovery information, when you click the “Get details” button in the Authorization Server Configuration page while creating the same in CMC.Hence in such cases you need to manually enter the conventional token_endpoint url, in the Token Endpoint text box. As mentioned above, for Microsoft Entra Id it will be as following: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token (replace tenant value with your tenant identifier)This is because, In BI Platform, the OAuth 2.0 Token implementation for OAuth SSo or for OIDC authentication, it is implemented based on the Client ID and Client Secret only, Certificate based Client Authentication is not yet supported.Enter the Client ID value in the corresponding text box. (This is the Application (Client) Id which is registered at the Authorization Server for this configuration purpose, refer the above section)Enter the Client Secret value in the corresponding text box. (This is the Client Secret value you have saved securely after creating it during the Application registration in Authorization Server, refer step 12 in the “Authorization Server Configuration steps” section above, enter that value here.)Enter the Redirect URL in the corresponding text box. (This should exactly match with the value you have entered for the Redirect URI during the Application registration in Authorization Server, refer step 7 in the “Authorization Server Configuration steps” section above, enter that value here.), which will be in the following format: https://<biphostname>:<port>/biprws/v1/oauth2/callback.(Optional) Enter the Revocation Endpoint in the corresponding text box. (If your Authorization Server provides one). For Microsoft Entra Id I believe this is as following: https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/logout.Select Type of Resource as Agnostic (which is default value), if you are planning to use this configuration just for OpenID Connect Authentication and/or for any resource access using OAuth SSO. But if you plan to use the same configuration to access Cloud (Drive) storage or OData resource, then select the type accordingly.For example, for the case we are referring here is Microsoft Entra ID then same configuration can be used for “Microsoft Drive”, access as well.Access Type field is specific to Google configuration, this is non-editable field, will be considered automatically with an hardcoded value “Offline” when you select Type of Resource as “GoogleDrive”.(Optional) Custom Parameters field can be used to save any custom parameters required based on your organizational needs according to the configuration done at your Authorization server. Multiple such entries can be entered by clicking on the option +Add more Custom Parameters…At this moment you can save the configuration by clicking on OK button. Alternatively you can test the configuration entered by clicking on Test Connection button.In case if you plan to test the configuration first and then save, after completing the test, ensure to to re-enter the Client Secret value before clicking on the OK button to save the configuration.When editing the saved configuration, after completing the editing, you need to re-enter the Client Secret value, before clicking on the OK button to save the configuration.Once the form is submitted while creating new or edit the existing, client secret value will not be sent back from the backend (CMS) as this is sensitive data. Hence every time you need re-enter the Client Secret, before saving the configuration, otherwise Client Secret stored previously will be corrupted with the null or junk value in the backend, and all the Authorization and Token workflows will fail.Once the Authorization Server configuration which is enabled for OpenID Connect Authentication is saved then proceed for the next phase of configuration in the CMC, i.e. selecting this configuration as the configuration to be used for OpenID Connect Authentication.Navigate to Authentication section under Manage in the Home page.Click on “Enterprise” from the list of authentication methods.Note:Please be noted that, OpenID Connect Authentication in BI Platform is implemented on top of “Enterprise” authentication. This means, only user accounts with Enterprise alias will be able to perform the OpenID Connect Authentication into BI Launchpad.Hence the expectation is all the user accounts in your Identity Provider (IDP) who are expected to perform OpenID login to BI Platform should have corresponding user account in BI Platform with Enterprise alias and same email-id should be available with that user alias, which is there in the user profile for that account at IDP. This in turn tells the behavior that, BI Platform will try to find the user account in BI Platform with the matching email-id upon the successful Authorization to allow the user to login to BI Platform. As BI Platform supports only email claim.In the Enterprise authentication settings page, under “OpenID Connect Authentication” section, select the check-box related to OpenID Connect Authentication to make it enabled.And then Select the Authorization Server for OpenID Connect Authentication drop down with the configuration name created above in Step 22 of this section.Once the OpenID Connect Authentication is enabled in the backend, then proceed for the next phase of configuration in the CMC, i.e. to import / create user accounts with Enterprise alias having the same Email-id.You can achieve this in multiple waysManually creating the user by Navigating to Users and Groups section in Home page and click on Manage –> New –> New User option and fill the values for Name, description, password and especially enter the Email with the same email-id which is there for the corresponding user account in IDP.Importing bulk users – Please refer following SAP Knowledge Base Article 1780406.Automate creation of user accounts using BI Platform Java SDK or REST SDK. By programmatically querying the user details in IDP and create them as Enterprise users in BI Platform with the same email Id.With this Configuration at CMC side is completed.
BI Platform : BI Launchpad configuration
Once the configuration at Central Management Console is completed, proceed to BI Platform side configuration. As mentioned above OIDC based login is implemented only for BI Launchpad and OpenDocument applications in BI Platform.
As specified above OIDC implementation in BI Platform is in backend side configuration, so here in frontend side from the BILP and OD applications we just need to enable openid to indicate the application to initiate the OIDC login flow. For that we need to do the following changes in the corresponding properties of the applications.
Login to the machine where the BI Platform Web applications are deployed.Stop the application serverNavigate to the folder where the web applications are deployedIn the BOE webapp folder, copy “FioriBI.properties” and “OpenDocument.properties” from WEB-INF/config/default to WEB-INF/config/custom folder.open these two files from custom folder in any text editorfrom both the files keep only the following two properties and remove all the otherlogon.webssoauthnetication.frameworkopenid.restful.urlSet “logon.webssoauthnetication.framework” value to OpenId in both the files.Set “openid.restful.url” to restful webservices url of the landscape for example https://<server>:<port>/biprws. in both the files.Save both the files and start the application server. #To Enable Web SSO Authentication workflow. Possible values are (None,OpenId,SAML)
logon.webssoauthnetication.framework=OpenId
# set the Restful URL which is provided in CMC. example: http://<hostname>:<portNo>/biprws
openid.restful.url=https://<server>:<port>/biprwsNote: These settings will precedes all the other SSO login configurations supported by BOE web applications. This means for BILP, if you enable this WEBSSO method by setting “logon.webssoauthnetication.framework” then this will precede even if you configure other traditional SSO methods in the .properties file.You can choose to configure the above steps only for BI Launchpad only.You can deploy BOE web applications on different node for enabling the OpenID so that you can target specific groups of users to use this method of login, so that other deployments can serve for the group of users who need to use basic authentication or other methods of SSO login.As you can observe, in the above code snippet, sample for the properties file, either OpenID Connect or SAML any one mechanism only you can enable for your web applications.You can login to the BI Launch Pad via OpenID using …./BOE/BI/ url, however, once you login using the OpenID Connect authentication to BI Launch Pad you can observe that a dummy context path “WEBSSO” will be added to the url, and this will stay on the url path even after logging out.
Now your landscape is ready to allow the logins based OpenID Connect authentication into BI Launchpad and / or OpenDocument applications. When user access the …/BOE/BI/ url then it will take you to the Authorization Server login page once user authorizes themselves then BI platform will find the matching user with the help of email claim from ID Token, and if user exists with the matching email, then login will be allowed with that user account.
Best Wishes…
-Venkat.
Introduction : OpenID Connect (OIDC)Let’s kick things off by quickly understanding what OpenID Connect (OIDC) is:OpenID Connect (OIDC) is a simple and secure way for apps and websites to confirm who you are—without making you create yet another password. It’s built on top of OAuth 2.0, a widely used standard for secure access. Instead of storing passwords, OIDC lets your app rely on a trusted service (called an Authorization Server) to handle login. When you sign in, the app gets a verified “identity token” and some basic profile details, so it knows who you are.Why is this great?Safer: No password storage means fewer chances of data breaches.Convenient: Works across web, mobile, and JavaScript apps.Flexible: Supports extra features like encrypted data and single sign-out.In short, OIDC answers the question: “Who is using this app right now?”—in a secure, modern way.So, what is Authorization Server and how it is related to Identity check and Authentication…..Identity Provider (IdP): This is the service that authenticates the user and provides identity information (claims), in simple terms, Who authenticates the user and provides identity data.. Examples: Azure AD, Okta, Google Identity, SAP Cloud Identity Services.Authorization Server: This is the component that issues tokens (ID token, access token) as part of the OAuth 2.0/OIDC flow, in simple terms, Who issues tokens and enforces OAuth/OIDC protocol. It handles the authorization and token exchange.In most implementations, the Identity Provider and Authorization Server are part of the same system. For example: Azure AD acts as both IdP and Authorization Server. Okta does the same.So, while they play conceptually different roles, in practice, you’ll often configure just one endpoint because the IdP usually includes the Authorization Server functionality.Following is the simple block diagram explaining the OIDC flow: Now that we know what OIDC is and why it matters, let’s move on to see how you can configure it in SAP BusinessObjects BI Platform. Starting with BI 4.3 SP02, SAP BusinessObjects BI Platform introduced native support for OpenID Connect (OIDC) authentication. This means BI Launchpad can now leverage modern, secure, and password-free login flows using trusted identity providers like SAP Cloud Identity Services, Azure AD or Google…Note: This information in the below sections are applicable for BI 4.3 SP02 and above and BI 2025 versions.For this explanation I have used Azure AD (Microsoft Entra ID) as an Authorization Server / Identity Provider. Otherwise, you can use, any of the Authorization Server / Identity Provider which supports OAuth 2.0 protocol & OIDC. Back to top ⮭ BI Platform : OIDC Authentication in nutshellAs mentioned in my what’s new blog for BI 4.3 SP02 release, OIDC authentication is introduced along with the OAuth SSO functionality. Let us see, what we need to know about OIDC authentication implementation in BI Platform:OpenID Connect Authentication is implemented in BI Platform on top of Enterprise Authentication. Works with all the Authorization Server / IDP which support OpenID Connect Authentication based on OAuth 2.0 protocol.Uses the Authorization Server configuration in Central Management Console, this means it uses the configuration stored in the BI Platform backend. User base at your IDP, with which you are planning to use OIDC in BI Platform should have corresponding user accounts in BI Platform as an Enterprise aliases with the same Email (as BI Platform implementation for OIDC is based on email claim only.) which is configured for those users at IDP. Hence, these user accounts in BI platform need to be created in advance. (Please refer point 24 in the Central Management Console configuration section below). OpenID Connect Authentication in BI Platform is only supported for BI Launchpad and OpenDocument client applications.It is mandatory to enable HTTPS for the web applications (BOE & biprws) to configure OAuth SSO and / or OpenID Connect Authentication in BI Platform, as most Authorization Servers or IDPs insist to configure Redirect URI with https (Please refer Point no. 7 in Authorization Server configuration steps section below). Moreover using https is secure way and recommended method for communication over the wire. Back to top ⮭ BI Platform : OIDC Authentication vs SAML AuthenticationAs you already aware that BI Platform also supports SAML (Security Assertion Markup Language) based Authentication for web applications like BI Launchpad and CMC, wondering which method is recommended?As you know, SAML Authentication support in BI Platform exists much earlier, that is from BI 4.2 SP05 release onwards. And it was the de facto choice for many organizations deploying SAP BusinessObjects. As it was better choice that time when compared existing authentication methods, when compared to the basic authentication (password based) in security perspective and to platform native SSO methods (like Windows AD, LDAP or SAP) in complexity and modern protocol perspective.But now that BI Platform also got OpenID Connect Authentication support, so let us see which is better and recommended choice….FeatureSAML (Security Assertion Markup Language)OpenID Connect (OIDC)Primary goal(Core Function)Authentication & Authorization (XML-based assertions) using IdP→SP trust and SAML assertions.Authentication (identity verification)standard way to get identity claims& Authorization (via OAuth)Message & token format(Data Format)XML (Heavyweight, complex)JSON Web Tokens (JWTs) (Lightweight, simple)Protocol StandardsXML StandardsOAuth 2.0 (extension of it)User ExperienceCan be more complex/heavyweight.Simpler, smoother with user-agent redirection (e.g., “Sign in with SSO”).IntegrationCan be complex to implementEasier integrationTransport styleVarious bindings (HTTP Redirect, POST, SOAP)Simple HTTPS flows (HTTP Redirect, POST).Actors / terminologyIdentity Provider (IdP) and Service Provider (SP) exchanging AuthnRequest/Response and assertionsOpenID Provider (OP) and Relying Party (RP/client); uses OAuth-style endpoints.How the “login result” is deliveredTypically via browser POST/Redirect bindings carrying SAML Response back to SP’s ACS endpointTypically via redirects to RP with tokens/code (Authorization Code / Implicit / Hybrid flows are defined)Identity attributes / claimsAttributes carried as XML attributes inside the assertion; relies on SP/IdP agreement (often via metadata + mapping) Uses claims carried in JWT and/or returned by UserInfo (scopes map to claim sets).Metadata / discovery Typically depends on SAML metadata exchange (XML metadata with endpoints/certs) before federation works OIDC ecosystems commonly use standardized discovery patterns (OIDC defines a broader spec family including discovery/registration) Typical pain pointsXML + signing/encryption + metadata can be verbose and configuration-heavy compared to OIDC Must choose correct flow and validate tokens properly; still requires careful security configurationBIP: End-to-End DB SSO (for reporting DBs)NoYesBIP: Works without Trusted Authentication enabled in BI PlatformNoYesBIP: Native implementation (without using third party software)No (And moreover SAML implementation in BI Platform is at the level of Application Server and BI Platform backend does not know about it, as mentioned in the above point, BIP treats it as a Trusted Authentication)YesBIP: RoadmapNo plans to improve or innovate only maintenanceInnovations / Improvements are lined upAs you can see with the above comparison, it is evident that OIDC is the better choice when compared to SAML in BI Platform, and also OIDC is recommended as it is the latest and based on modern protocol.Hope you got the fair Idea about What is OIDC, and how it is implemented in BI Platform, why you can choose to go for it against legacy and SAML Authentication. So, let us move on to configuration part. Here’s how you can set it up step by step…… Back to top ⮭ Authorization Server : configuration stepsTo enable OpenID Connect (OIDC) authentication for any client application, the first step is to register that application (known as the Relying Party—in this case, the BI Platform) with the Authorization Server. This registration ensures that when the client initiates an OpenID Connect request, the OpenID Provider (OP) or Authorization Server can identify and trust the client application. By establishing this trust relationship, the Authorization Server can securely issue tokens and provide user identity information to the registered client.Sign in to your Authorization Server admin PortalHere in our example Authorization Server is Microsoft Entra ID, hence, go to https://portal.azure.com.Navigate to Microsoft Entra ID (previously Azure Active Directory).In Microsoft Entra ID, select App registrations under Manage sectionClick New registrationEnter Name: A descriptive name for your app. for ex: BIPOpenIDAuthselect Supported account types, according to your organizational needsEnter Redirect URI, by selecting the Web as the platform, the following url – https://<biphostname>:<port>/biprws/v1/oauth2/callbackNote: Replace “biphostname” and “port” with your BOBJ web application deployment details.It is mandatory and also the secure way to use https url.Click RegisterAfter registration, note down Application (Client) ID, Directory (tenant) ID, from the Overview section of the registered application.Go to Certificates & Secrets and click on New client secretAdd description and select expiry.Copy the secret value (you will need this along with Client ID for configuration in CMC)Note: The secret value is displayed only once immediately after creation. Make sure to copy and store it securely at that time. Once you leave this page, the secret will no longer be visible and cannot be retrieved later.Under API permissions, ensure openid, profile, email, and User.Read permissions are added from Microsoft Graph API as Delegated permissions by clicking on Add a permission(Optional) Add Files.ReadWrite.All and offiline_access permissions, if in case, if you want to use the same configuration for making Microsoft OneDrive as Scheduling destination as well as use Office documents as data source for Web Intelligence documents.Add any additional permissions your app needs.Grant admin consent if required.Collect the following details, before proceeding for the next stepDirectory (tenant) IDIssuer URL – https://login.microsoftonline.com/{tenant}/v2.0Application (Client) IDClient Secret (secret value)Redirect URL Back to top ⮭ BI Platform : Central Management Console ConfigurationAfter completing the configuration on the Authorization Server and obtaining the necessary application details, you can proceed to the Central Management Console (CMC) to configure the BI Platform side. As mentioned in the introduction, SAP BusinessObjects BI Platform introduced native support for OpenID Connect (OIDC) starting with BI 4.3 SP02, along with the underlying OAuth SSO feature. I’ve explained OAuth SSO in detail in another blog, where you’ll also learn about a new application called Authorization Server Configuration under the Applications section in CMC. This application serves as the foundation for all OAuth SSO-based functionalities in the BI Platform, including OAuth SSO for databases and OData, OIDC-based authentication, and scheduling to cloud storage services such as Google Drive and Microsoft OneDrive.launch http://<biphostname>:<port>/BOE/CMC/ and login with Administrator or delegated admin account having privileges to manage ApplicationsNavigate to Applications under Manage sectionRight click on Authorization Server Configuration and select the Authorization Server Configurations option.In Authorization Server Configurations pop up, select New Authorization Server Configuration option from Manage drop down menu.Enter the desired configuration name in the Reference Name text box.(Optional) Enter the relevant description text in the Description text box.If you are using BI 2025 and above, then you will see the option to choose the Grant Type, in that keep the default option Authorization Code.Note:In earlier versions of BI Platform (Prior to BI 2025), this option was not available, and Authorization Code Grant Type was implicit value in those BI Platform versions.Authorization Code flow is most secure and recommended Grant Type for the OIDC Authentication scenario. BI Platform only allows OIDC authentication via the Authorization Code flow grant type only.BI Platform was only supporting Authorization Code flow priori to BI 2025, but from BI 2025 onwards, it supports Authorization Code flow & Client Credentials flow.Authorization Code flow for OIDC & OAuth SSO scenarios.Client Credential flow for OAuth SSO scenarios. (which is meant for server-to-server or machine-to-machine authorization)For more information on Grant Types refer OAuth 2.0 Authorization Framework.Select the checkbox labeled Enabled for “OpenID Connect” Authentication, to indicate the configuration is ready for using the OpenID Connect (OIDC) Authentication.Observe that, Issuer URI, JSON Web Key Sets URI (jwks_uri) and ID Token Signing Algorithm fields gets enabled.Enter the Issuer URI in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/v2.0 (replace tenant value with your tenant identifier)(Optional) Click on Get details button next to Issuer URI text box after entering the correct value.CMC UI has functionality implemented to fetch and fill the values automatically for JSON Web Key Sets URI (jwks_uri), Authorization Endpoint, Token Endpoint.If you do not want use this Get details functionality then you need to fill jwks_uri, authorization endpoint and token endpoint manually.Enter the JSON Web Key Sets URI (jwks_uri) (if not fetched through Get details), in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys (replace tenant value with your tenant identifier)For ID Token Signing Algorithm, BI Platform supports only RS256, hence it is the only value available in the list and selected by default.Enter the Authorization Endpoint (if not fetched through Get details), in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize (replace tenant value with your tenant identifier)Enter the Token Endpoint (if not fetched through Get details), in the corresponding text box. for Microsoft Entra ID, it is https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token (replace tenant value with your tenant identifier)Note:If in case, your Authorization server, which you are planning to use for configuring OIDC Authentication in BI Platform is capable of and enabled with “OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens” then in the Token Endpoint text box may get filled with the alternative token endpoint than the conventional end point.Because when Mutual TLS Client Authentication and Certificate-Bound Access Tokens functionality enabled at the Authorization server side, then the OpenID Connect discovery will contain the “mtls_endpoint_aliases” JSON object consists of one or more endpoint parameters, such as token_endpoint, revocation_endpoint, introspection_endpoint, etc. For more information on mtls_endpoint_aliases refer RFC 8705.Here is the example for Microsoft Entra Id with common discovery url, where in which you can observe the “mtls_endpoint_aliases” with an alternative token_endpoint along with conventional token_endpoint url… which will be in the following format: https://mtlsauth.microsoft.com/{tenantid}/oauth2/v2.0/token {
“token_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/token”,
“token_endpoint_auth_methods_supported”: [
“client_secret_post”,
“private_key_jwt”,
“client_secret_basic”,
“self_signed_tls_client_auth”
],
“jwks_uri”: “https://login.microsoftonline.com/common/discovery/v2.0/keys”,
“response_modes_supported”: [
“query”,
“fragment”,
“form_post”
],
“subject_types_supported”: [
“pairwise”
],
“id_token_signing_alg_values_supported”: [
“RS256”
],
“response_types_supported”: [
“code”,
“id_token”,
“code id_token”,
“id_token token”
],
“scopes_supported”: [
“openid”,
“profile”,
“email”,
“offline_access”
],
“issuer”: “https://login.microsoftonline.com/{tenantid}/v2.0”,
“request_uri_parameter_supported”: false,
“userinfo_endpoint”: “https://graph.microsoft.com/oidc/userinfo”,
“authorization_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/authorize”,
“device_authorization_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/devicecode”,
“http_logout_supported”: true,
“frontchannel_logout_supported”: true,
“end_session_endpoint”: “https://login.microsoftonline.com/common/oauth2/v2.0/logout”,
“claims_supported”: [
“sub”,
“iss”,
“cloud_instance_name”,
“cloud_instance_host_name”,
“cloud_graph_host_name”,
“msgraph_host”,
“aud”,
“exp”,
“iat”,
“auth_time”,
“acr”,
“nonce”,
“preferred_username”,
“name”,
“tid”,
“ver”,
“at_hash”,
“c_hash”,
“email”
],
“kerberos_endpoint”: “https://login.microsoftonline.com/common/kerberos”,
“mtls_endpoint_aliases”: {
“token_endpoint”: “https://mtlsauth.microsoft.com/common/oauth2/v2.0/token”
},
“tls_client_certificate_bound_access_tokens”: true,
“tenant_region_scope”: null,
“cloud_instance_name”: “microsoftonline.com”,
“cloud_graph_host_name”: “graph.windows.net”,
“msgraph_host”: “graph.microsoft.com”,
“rbac_url”: “https://pas.windows.net”
}As mentioned in the above point, Token Endpoint text box gets filled with this alternative token_endpoint value, due to some issue in parsing the discovery information, when you click the “Get details” button in the Authorization Server Configuration page while creating the same in CMC.Hence in such cases you need to manually enter the conventional token_endpoint url, in the Token Endpoint text box. As mentioned above, for Microsoft Entra Id it will be as following: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token (replace tenant value with your tenant identifier)This is because, In BI Platform, the OAuth 2.0 Token implementation for OAuth SSo or for OIDC authentication, it is implemented based on the Client ID and Client Secret only, Certificate based Client Authentication is not yet supported.Enter the Client ID value in the corresponding text box. (This is the Application (Client) Id which is registered at the Authorization Server for this configuration purpose, refer the above section)Enter the Client Secret value in the corresponding text box. (This is the Client Secret value you have saved securely after creating it during the Application registration in Authorization Server, refer step 12 in the “Authorization Server Configuration steps” section above, enter that value here.)Enter the Redirect URL in the corresponding text box. (This should exactly match with the value you have entered for the Redirect URI during the Application registration in Authorization Server, refer step 7 in the “Authorization Server Configuration steps” section above, enter that value here.), which will be in the following format: https://<biphostname>:<port>/biprws/v1/oauth2/callback.(Optional) Enter the Revocation Endpoint in the corresponding text box. (If your Authorization Server provides one). For Microsoft Entra Id I believe this is as following: https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/logout.Select Type of Resource as Agnostic (which is default value), if you are planning to use this configuration just for OpenID Connect Authentication and/or for any resource access using OAuth SSO. But if you plan to use the same configuration to access Cloud (Drive) storage or OData resource, then select the type accordingly.For example, for the case we are referring here is Microsoft Entra ID then same configuration can be used for “Microsoft Drive”, access as well.Access Type field is specific to Google configuration, this is non-editable field, will be considered automatically with an hardcoded value “Offline” when you select Type of Resource as “GoogleDrive”.(Optional) Custom Parameters field can be used to save any custom parameters required based on your organizational needs according to the configuration done at your Authorization server. Multiple such entries can be entered by clicking on the option +Add more Custom Parameters…At this moment you can save the configuration by clicking on OK button. Alternatively you can test the configuration entered by clicking on Test Connection button.In case if you plan to test the configuration first and then save, after completing the test, ensure to to re-enter the Client Secret value before clicking on the OK button to save the configuration.When editing the saved configuration, after completing the editing, you need to re-enter the Client Secret value, before clicking on the OK button to save the configuration.Once the form is submitted while creating new or edit the existing, client secret value will not be sent back from the backend (CMS) as this is sensitive data. Hence every time you need re-enter the Client Secret, before saving the configuration, otherwise Client Secret stored previously will be corrupted with the null or junk value in the backend, and all the Authorization and Token workflows will fail.Once the Authorization Server configuration which is enabled for OpenID Connect Authentication is saved then proceed for the next phase of configuration in the CMC, i.e. selecting this configuration as the configuration to be used for OpenID Connect Authentication.Navigate to Authentication section under Manage in the Home page.Click on “Enterprise” from the list of authentication methods.Note:Please be noted that, OpenID Connect Authentication in BI Platform is implemented on top of “Enterprise” authentication. This means, only user accounts with Enterprise alias will be able to perform the OpenID Connect Authentication into BI Launchpad.Hence the expectation is all the user accounts in your Identity Provider (IDP) who are expected to perform OpenID login to BI Platform should have corresponding user account in BI Platform with Enterprise alias and same email-id should be available with that user alias, which is there in the user profile for that account at IDP. This in turn tells the behavior that, BI Platform will try to find the user account in BI Platform with the matching email-id upon the successful Authorization to allow the user to login to BI Platform. As BI Platform supports only email claim.In the Enterprise authentication settings page, under “OpenID Connect Authentication” section, select the check-box related to OpenID Connect Authentication to make it enabled.And then Select the Authorization Server for OpenID Connect Authentication drop down with the configuration name created above in Step 22 of this section.Once the OpenID Connect Authentication is enabled in the backend, then proceed for the next phase of configuration in the CMC, i.e. to import / create user accounts with Enterprise alias having the same Email-id.You can achieve this in multiple waysManually creating the user by Navigating to Users and Groups section in Home page and click on Manage –> New –> New User option and fill the values for Name, description, password and especially enter the Email with the same email-id which is there for the corresponding user account in IDP.Importing bulk users – Please refer following SAP Knowledge Base Article 1780406.Automate creation of user accounts using BI Platform Java SDK or REST SDK. By programmatically querying the user details in IDP and create them as Enterprise users in BI Platform with the same email Id.With this Configuration at CMC side is completed. Back to top ⮭ BI Platform : BI Launchpad configuration Once the configuration at Central Management Console is completed, proceed to BI Platform side configuration. As mentioned above OIDC based login is implemented only for BI Launchpad and OpenDocument applications in BI Platform.As specified above OIDC implementation in BI Platform is in backend side configuration, so here in frontend side from the BILP and OD applications we just need to enable openid to indicate the application to initiate the OIDC login flow. For that we need to do the following changes in the corresponding properties of the applications.Login to the machine where the BI Platform Web applications are deployed.Stop the application serverNavigate to the folder where the web applications are deployedIn the BOE webapp folder, copy “FioriBI.properties” and “OpenDocument.properties” from WEB-INF/config/default to WEB-INF/config/custom folder.open these two files from custom folder in any text editorfrom both the files keep only the following two properties and remove all the otherlogon.webssoauthnetication.frameworkopenid.restful.urlSet “logon.webssoauthnetication.framework” value to OpenId in both the files.Set “openid.restful.url” to restful webservices url of the landscape for example https://<server>:<port>/biprws. in both the files.Save both the files and start the application server. #To Enable Web SSO Authentication workflow. Possible values are (None,OpenId,SAML)
logon.webssoauthnetication.framework=OpenId
# set the Restful URL which is provided in CMC. example: http://<hostname>:<portNo>/biprws
openid.restful.url=https://<server>:<port>/biprwsNote: These settings will precedes all the other SSO login configurations supported by BOE web applications. This means for BILP, if you enable this WEBSSO method by setting “logon.webssoauthnetication.framework” then this will precede even if you configure other traditional SSO methods in the .properties file.You can choose to configure the above steps only for BI Launchpad only.You can deploy BOE web applications on different node for enabling the OpenID so that you can target specific groups of users to use this method of login, so that other deployments can serve for the group of users who need to use basic authentication or other methods of SSO login.As you can observe, in the above code snippet, sample for the properties file, either OpenID Connect or SAML any one mechanism only you can enable for your web applications.You can login to the BI Launch Pad via OpenID using …./BOE/BI/ url, however, once you login using the OpenID Connect authentication to BI Launch Pad you can observe that a dummy context path “WEBSSO” will be added to the url, and this will stay on the url path even after logging out.Now your landscape is ready to allow the logins based OpenID Connect authentication into BI Launchpad and / or OpenDocument applications. When user access the …/BOE/BI/ url then it will take you to the Authorization Server login page once user authorizes themselves then BI platform will find the matching user with the help of email claim from ID Token, and if user exists with the matching email, then login will be allowed with that user account. Back to top ⮭ Best Wishes…-Venkat. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
