How to onboard an application to Siemens Entra ID (Azure AD) single sign-on (OIDC/SAML)¶

This page constitutes an end-to-end guide for onboarding an application to Entra ID. This includes the creation of an application integration, as well as its configuration. If you want to migrate an existing MyID application, you can in addition make use of our specific guide: How to migrate an application from MyID to Siemens Entra ID.

Register an application in EntraID¶

Find more detailed documentation on the official siemens wiki: wiki.siemens.com

If your app is already registered, please skip this steps

1. Step 1: Create a new app integration in Self-Service Portal
   Go to Siemens Entra ID Self-Service Portal
   Click on + Create Application Integration

2. Step 2: Configure your app integration in Entra ID
   For OIDC (and OAuth 2.0 / Graph API):
   
   

   • Select your newly created app from Entra ID Portal - App Registration List
   • Configure the required OIDC values (Redirect URI, Client Secret, etc.)
   • Configure whether to restrict which "Users and Groups" should be able to authenticate.

3. Step 3: Configure your app itself
   Configure your application itself (configuration files, code etc.), so it uses the Entra ID app integration.
   Details depend on your application.

Ask for permission to consume the Norm-Service¶

Create a Ticket in TIMA and ask for permission. Send us the Client-ID of your created or existing EntraID application.

https://tima.siemens.com/otwg20

Ticket Template:

In what environment the request is for, TEST or PROD? 
Consumer Application name:
More details about the application (onepager, quick presentation, etc):
Whom are the relevant for people for important communications (Service Manager; Service Owner; Product Owner; etc.)?

Estimated request volume:
Per month:
Per day:
Any specific peaks:

Is your application already registered in EntraID?
If yes, please provide the Client ID:
If no, please register your application and then provide the Client ID.

Get an access token from your registered Application¶

Before this flow can be used, the client must register with the OAuth server same as for authorization code grant flow. After successful registration the client receives a client_id and a client_secret.

Access Token some time just called as token is issued by Authorization Server to the Client. It indicates the rights that the Client has which are delegated by the User. The client sends the token to the resource server when accessing the Protected Resource.

Access tokens are opaque to the Client, and the client’s job is to carry the token, requesting it from the authorization server and presenting it to the protected resource.

The Scope "61d62918-bf2a-4aa1-8a96-7659cefdbc69/.default" is very important and must not be changed