Hi,
IBM Verify access has a number of options to integrate, but it all depends on the capabilities of the application. From the drawing I could make a couple of observations. Making API calls, consulting an AD, returning a JWT.
Verify access can send a JWT to an application. As the technology in use is IIS , there are a couple of SSO integrations possible such as sending a header , being consumed by the application, there were integrations with AD possible, Kerberos is an option, SAML is an option.
Verify Access can perfectly integrate with AD as Federated registry and hence there is no need to send it to AD (could still be done)
I see a couple of options/ patterns
- OIDC pattern (Authorization code flow) : your application redirect the user to Verify Access (OIDC provider) . User authenticates against Verify Access (AD as federated registry). Your application exchanges authorization grant for access token and id_token. The application sends a Access token (can be in JWT format) to the API layer . The API layer calls the introspect endpoint to validate the access token and calls next the Database.
- Federated Registry pattern + JWT header
See also previous example for FedReg pattern. Verify Access can send a JWT to the backend (requires also AAC/Federation module). API layer leverages the JWT.
- Kerberos tokens
IIS can perfectly be configured for Kerberos constrained delegation. Verify access can perform authentication , obtain Kerberos tokens by calling the KDC and sending those to the application
There are some additional options but you have here the main ideas.
Again really depends on the application
Kind regards
Serge Vereecke
------------------------------
Serge Vereecke
------------------------------
Original Message:
Sent: Tue April 06, 2021 07:26 AM
From: Prashant Narkhede
Subject: ISAM - Need guidance to decide the integration approach for SSO
Hi Dennis,
Thank you for your inputs.
No, back-end cannot consume the Kerberos to authenticate.
Can we integrate with some other way?
Regards,
Prashant Narkhede
------------------------------
Prashant Narkhede
Original Message:
Sent: Tue April 06, 2021 05:31 AM
From: Dennis English
Subject: ISAM - Need guidance to decide the integration approach for SSO
Can the back-end application consume Kerberos tokens to authenticate?
If so, then perhaps the answer is to configure ISAM to authenticate the user using Kerberos, and then provide the back-end with kerberos delegation token that it can use instead of username/password authentication
------------------------------
Dennis English
Original Message:
Sent: Mon April 05, 2021 06:35 AM
From: Prashant Narkhede
Subject: ISAM - Need guidance to decide the integration approach for SSO
Hi Team,
Our customer has an application with a front-end and back-end application layer.
The front-end layer communicates with the back-end via the JWT token.
Refer to the attached login flow image.
We have already integrated the customer Active Directory as a federated registry. Also, we have integrated the SAML-based SSO for one application successfully.
I tried this application integration by modifying the application as EAI. For this, we have created an additional WebSEAL instance and a further plan to setup the session sharing between WebSEAL instances. But it didn't work as EAI.
Can someone guide me on how to fit this application for SSO? What is the best possible approach to do this?
Regards,
Prashant Narkhede
------------------------------
Prashant Narkhede
------------------------------