IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  OIDC Implementation for Junction server

    Posted Mon November 30, 2020 05:01 PM
    is it possible to implement SSO with OIDC for Third party applicaiton which supports OIDC only ?? . We have implemented SSO with ETAI for websphere portal. We need to access third pary application from portal. Third party applicaiton  is webseal junctioned server on same security domain. appreciate your suggestions

    ------------------------------
    Anji Babu
    ------------------------------


  • 2.  RE: OIDC Implementation for Junction server

    Posted Tue December 01, 2020 02:45 AM
    This question does not make any sense. OIDC is by definition a federated SSO protocol, and therefore is not a junction-based SSO mechanism.

    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message


  • 3.  RE: OIDC Implementation for Junction server

    Posted Tue December 01, 2020 01:45 PM
    Understood Shane. Trying to figure out options for implementing SSO from portal application to internal application which supports OpenID. Junction-based SSO is used for portal ( ETAI )

    ------------------------------
    Anji Babu
    ------------------------------

    Original Message


  • 4.  RE: OIDC Implementation for Junction server

    Posted Tue December 01, 2020 04:22 AM
    Hi Anji,

    If you really mean OIDC (as in the browser protocol that allows federation), it would be unusual for the target server ("Relying Party") to be behind a junction.  OIDC is specifically designed to allow identity assertion between two servers that are independent.  Application access after the federation flow is usually direct to the target server - not going via the Reverse Proxy.  I suppose it *might* be possible to perform the federation to the target while the target is also behind a junction - but this would be a non-standard approach.

    OIDC uses JSON Web Tokens (JWT) to carry assertion data.  It is also possible to use a JWT in an HTTP header to provide direct SSO on a junction.  Perhaps this is what you mean?  This is supported by Verify Access.  There is a pattern for WebSphere Liberty which supports this. It uses the same Liberty module that is used to support OIDC (so maybe that is also a source of confusion).  If this is what you're trying to do, have a look at this blog post:
    https://www.ibm.com/blogs/sweeden/isam-9-0-2-the-jwt-sts-module-and-junction-sso-to-websphere-liberty/

    In Verify Access v10, there is native support for generating (simple) JWT built into the Reverse Proxy - so that you don't need the federation runtime and STS.  You might be able to adapt the pattern above to use this instead for a simple use case: 
    https://www.ibm.com/support/knowledgecenter/SSPREK_10.0.0/com.ibm.isva.doc/wrp_config/concept/con_json_web_token_https.htm

    I hope this helps.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 5.  RE: OIDC Implementation for Junction server

    Posted Wed December 02, 2020 04:51 AM
    Hi Anji,

    Of course it is possible to configure an OIDC federation to a third party application which is behind a WebSEAL junction on the same domain. The fact that the Relying Party is behind a junction doesn't change anything for the configuration of OIDC.
    I also don't find that configuration so unusual. It is true that federation protocols such as OIDC and SAML are designed to be able to federate completely independent systems. But that does not preclude them from being used in environments where both systems are under your control.
    In fact we use it widely in our environment. Not yet for OIDC, but we have integrated several third party applications with SAML, and also protected these applications with WebSEAL. Of course we could also have federated the application in the traditional way and let the user directly access the back-end system, but as a security team we don't have too much trust in third party applications. We want to make sure that only authenticated and authorized users can access the system.

    ------------------------------
    Laurent LA Asselborn
    ------------------------------

    Original Message