My previous article about OAuth flow in IFS received many good feedback and I thought it would be nice to write something about how authentication works in IFS Cloud as well. If you need to know the basics of OAuth authentication, it’s a good idea to read the previous article since the concept is the same when it comes to IFS Cloud, except that only OAuth is the accepted authentication method for both client and for integrations.
In IFS Cloud, Authentication is separated and called as IFS Identity and Access Manager (IFS IAM). IFS IAM can have it’s own user registry or you can use third party identity provider like Azure AD for the authentication. All the requests coming to IFS is screening through a Proxy and the fundamental requirement is that the request should carry a valid access token.
You can define two types of users in IFS Cloud. End Users and Service Users. As the name suggests, End users are for client access and the service users are for integrations. Worth noting that the Service users neither does not account for the license cost nor can be configured using external identity provider. Therefore, if you have a external identity provider and need to access IFS via integration, then you should create a service user. Read through the post and you’ll know how 😎
In this post..
- OpenID Configurations
- End User Authentication (Authorization Code Flow)
- End User Authentication with Resource Owner Password Credentials (ROPC)
- Service User Authentication (Client Credentials Flow)
- Summary
OpenID Configurations
You can find the related information about the OAuth2 OpenID configurations by calling the OpenID Connect Discovery document. Go to the IFS Login page, copy the url until IFS namespace and append /.well-known/openid-configuration
Eg: https://my-prod.ifs.cloud/auth/realms/prod1/.well-known/openid-configuration
The resultant json document has all the endpoints, grant types supported and scopes
{
"issuer": "https://my-prod.ifs.cloud/auth/realms/prod1",
"authorization_endpoint": "https://my-prod.ifs.cloud/auth/realms/prod1/protocol/openid-connect/auth",
"token_endpoint": "https://my-prod.ifs.cloud/auth/realms/prod1/protocol/openid-connect/token",
"introspection_endpoint": "https://my-prod.ifs.cloud/auth/realms/prod1/protocol/openid-connect/token/introspect",
"userinfo_endpoint": "https://my-prod.ifs.cloud/auth/realms/prod1/protocol/openid-connect/userinfo",
"end_session_endpoint": "https://my-prod.ifs.cloud/auth/realms/prod1/protocol/openid-connect/logout",
"frontchannel_logout_session_supported": true,
"frontchannel_logout_supported": true,
"jwks_uri": "https://my-prod.ifs.cloud/auth/realms/prod1/protocol/openid-connect/certs",
"check_session_iframe": "https://my-prod.ifs.cloud/auth/realms/prod1/protocol/openid-connect/login-status-iframe.html",
"grant_types_supported": [
"authorization_code",
"implicit",
"refresh_token",
"password",
"client_credentials",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:openid:params:grant-type:ciba"
]
...
...
...
}We will use the values from this document throughout the post.
End User Authentication (Authorization Code Flow)
As mentioned above, all requests comes to IFS must carry a valid access token. If you are trying to login to IFS Aurena, any other IFS client or have built an app by yourself, same principle applies. If you have valid access token, then life is great and you can access IFS data via projections. But what if not?
If IFS Proxy could not validate the Access token in the request or if it does not have a Access Token, then it redirects the request to the Authorization endpoint at the IFS IAM where the user prompted with IFS login dialog to enter the credentials. Once successfully authenticated, the request is sent back to IFS Proxy which returns the data from the backend.
Below is the call sequence to get data from IFS projection to the user. If there’s no valid token present with the request, IFS Proxy redirects the request for authentication (steps 4 to11).
Note that the redirect happens only if IFS Proxy identifies the request is coming from a client which could handle redirects. All the modern browsers are capable of handling HTTP 302 and that’s how you get the Login prompt. If you are building own app or using a tool like Postman, then first, the access token needs to be obtained since it will not handle automatically.
Perform End User Authentication with Postman
IAM Client Setup
In order to connect to IFS via any client, client needs to register and register the callback URL. Go to IAM Client in IFS Cloud (Solution Manager > Users and Permissions > Identity and Access Manager > IAM Client) and Press + to create a new client. Fill the details as below and add the postman default callback URLs as the redirect Uri. Enable the client and Save.
Postman Redirect URLs
– Postman Web: https://oauth.pstmn.io/v1/browser-callback
– Postman App: https://oauth.pstmn.io/v1/callback
If these URLs doesn’t work, please check the Postman documentation to find the correct URLs
Postman Setup
Open Postman, Create a new Collection
Go to the Authorization tab of the collection and choose the type as OAuth 2.0. Provide values below
- Token Name – any name to identify the token
- Grant Type – Authorization Code (With PKCE)
- Callback URL – keep the default (if this url is different from what you added in the IAM client, add this to the redirect uri list)
- Auth URL- authorization_endpoint from the OpenID discovery document retrieved above
- Access Token URL- token_endpoint from the OpenID discovery document retrieved above
- Client ID- IAM client ID you provided in IFS
Press Get New Access Token and if you provided all necessary details and your IAM client is enabled, you should get the IFS login dialog as below. Provide username and password and then you should get the access token back!
Now this access token can be used to call IFS Projections. In the request, make sure Authentication is set to inherit from parent
Making a Confidential Client
In order to make a confidential client, just uncheck the Public Client radio-box in the IAM Client, copy the secret in the Postman Client Secret.
Public vs Confidential Clients
In the IAM client setup, we have set ours as a public client. That means it does not have a client secret associated with it. You can find loads of information in the web on what public and confidential clients are, and how I understood is that is; if we build an app which should be used by end users, best approach is to use a public client and if it’s allocated only to a known service or individual, then it should be a confidential client.
From the security perspective, confidential clients adds one more secure layer since we know who exactly the app/service accessing IFS and if there’s a security risk, we can quickly regenerate the secret to avoid malicious attacks.
End User Authentication with Resource Owner Password Credentials (ROPC)
If your app cannot render a browser and popup IFS Login dialog to authenticate the user, then there’s a choice of using the ROPC authentication. In this way, instead of authentication in IFS or 3rd party Identity provider, username and password is being sent directly from the app to the IAM which in return sends a access token.
In order to use ROPC, the IAM Client should setup to allow Direct Access Grants.
ROPC Flow with Postman
In order to get Access Token via ROPC flow, following configurations has to be changed from the end user authentication which we looked earlier.
- Grant Type- Password Credentials
- Username- IFS User ID
- Password- User Password
⚠️It is highly discouraged using the ROPC flow since username and password handling is done by the application and if there’s a breach in the app, it directly could affect the user credential safety.
Service User Authentication (Client Credentials Flow)
When building integrations with IFS, we need a user who granted with right permission for backend resources (projections) to make the request. As you may think, we can use the ROPC flow with hard coded end user id and password but it would exploit the user credentials and anyone with credentials can simply login to IFS clients.
In contrast, service user is specially designed for integrations and server-to-server communication and minimize the risk of exploiting the user credentials to 3rd party.
Service users are not allowed to login to IFS Aurena and should not grant more permission than what it should have. In addition, a service user must be a confidential IAM Client. By this way, we could minimize the risk of malicious access attempts and data breaches.
Unlike end users, service users does not have a password. Instead, they use the client id/secret to authenticate. Therefore it’s important to securely store the client id and the secret. Process for obtaining the token is almost equal to ROPC but we use client id and secret instead username and password.
In order to use client credentials flow, IAM client must be a
- Confidential client
- Associated with a service account
Service Account
A Service account is an identity created in IFS without the abilities of end user, means that it cannot login to IFS Clients. But you can grant permissions to service accounts the same way it’s being done for the end users. It’s a best practice to create separate service account for each integration and have dedicated permission sets for each service accounts so each integration can be isolated.
IAM Client Setup
As see above, Service account and Direct Access grants is checked. Once the record is saved, an IFS user will be created with the Username provided for the service account.
Now we need to setup the Service account user permissions.
I’ve created a new End User Permission set and added the Projection (PartHandling) I wanted to call with this service user and added that permission set to the user
If the records you need to access via integration requires application level setup (e.g.: Company, Site access), Service user can added just as a regular user.
Client Credentials Flow with Postman
In order to get Access Token via Client Credentials flow, following configurations has to be changed from the end user authentication which we looked earlier.
- Grant Type- Client Credentials
- Client ID- IAM client ID you provided in IFS
- Client Secret- IAM Client secret
Now you should be able to access the IFS Projections granted for this service user using the obtained access token.
Summary
Now you know how the authentication works in IFS Cloud. Main thing to keep in mind is that it only supports OAuth authentication for both end users and for integrations. Therefore make sure you can handle the access tokens in your app or the integration.
There are pros and cons of using each authentication flows and it’s always the security which should consider when deciding the right authentication pattern for you.
Thanks for reading and good luck with exploring IFS Cloud. If you like the article please share and comment!
Leave a Reply