IBM Security Verify

Expand all | Collapse all

ISAM - Need guidance to decide the integration approach for SSO

  • 1.  ISAM - Need guidance to decide the integration approach for SSO

    Posted 17 days ago
      |   view attached
    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
    ------------------------------


  • 2.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 16 days ago
    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
    ------------------------------



  • 3.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 16 days ago
    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
    ------------------------------



  • 4.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 15 days ago
    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
    ------------------------------



  • 5.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 15 days ago
    Edited by Joao Goncalves 15 days ago
    In fact I didn't understand you question. Apparently you want to change the .Net infrastructure with ISAM.
    The generation of the JWT is definitely something it does. I still have a few issues. The JWT claim, apparently comes after authenticating in both AD server and Database server.
    I really don't understand what is the role of the Database in this process, since the JWT is only returned after accessing the DB server!

    The claims are obtained from both AD and DB?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 6.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 15 days ago
    Hi Joao,

    The above attached image illustrates the current authentication and authorization flow of the customer application.
    I am looking for the best possible way to implement the SSO using ISAM 10 with minimum changes to the application code.

    Regards,
    Prashant Narkhede.

    ------------------------------
    Prashant Narkhede
    ------------------------------



  • 7.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 14 days ago
    Hi ,

    I understand the requirement that you want a minimal amount of changes on the application.  But your current application is already calling Active Directory for a authentication validation and probably also for some authorization check.  Adding Verify Access will require some changes and responsibilities
    As expressed in the previous conversation, use one of the following 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.

    If Verify Access is protecting the application, then you can not have an additional user authentication from the application against Active Directory. Use AD in the authentication step as Federated Registry.  Your API layer is already returning a JWT, so could equally consume a JWT originating from Verify Access.
    Kind Regards
    Serge Vereecke

    ------------------------------
    Serge Vereecke
    ------------------------------



  • 8.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 14 days ago
    Hi Prashant:
    You sitll haven't answered my question regarding the DB. You are using the term "AUTH" on both AD and DB. Do you mean authentication?
    I am assuming it is, as you are returning the JWT to angular accessing both.
    Why do you need to access the DB? Are there any field in the DB that are required to be added to the JWT?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 9.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 14 days ago
    Edited by Prashant Narkhede 14 days ago
    Hi Joao, 

    The DB is being used for authorization purpose. The role and permission associated with user are being stored in DB and by using it UI and links get loaded. 
    I have to confirm with application team that whether this role and permission information is getting bundled in JWT or not. 



    ------------------------------
    Prashant Narkhede
    ------------------------------



  • 10.  RE: ISAM - Need guidance to decide the integration approach for SSO

    Posted 14 days ago
    Edited by Joao Goncalves 13 days ago
    In my opinion, you have to split this into 2 parts:
    • Authentication
    • Authorization
    The JWT should be returned only with the user attributes if he is a valid user. It should not include details about authorization.

    So, after your application (your relying party) gets the JWT, and he now has the capability to grant or deny the access.
    If it requires to get the permissions in the DB to get them, so let it do it!

    ISVA can do both roles, but you would need to change the way you are doing things.

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------