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.  9.0.5 - Native OIDC integration

    Posted Tue July 24, 2018 05:12 PM
    Hi All,

    I've been playing around with the latest ISAM version, more specifically the new oidc authentication method.
    I have configured two OpenID Providers, where the redirects seem to work when I provide iss=google, iss=is4u, ... in the form.
    The problem exists when I set up a default-op, in this case I point to "google".
    As I said earlier, the redirect to the provider works, however when WebSEAL attempts to exchange the code for tokens, it will exchange them at the "default-op" token endpoint? Making it that the user is unable to authenticate.

    Is this expected behavior? It seems to indicate to work with multiple providers, however always exchanging at the default-op is strange.
    Furthermore, WebSEAL appended the local OP in the state:
    state=****:google, state=****:is4u, ...

    Some side notes:
    Setting default-op to "default" causes:
    DPWAD0412E The configuration entry found within the oidc stanza was not valid: default-op = default.
    Instance can not be started.

    Commeting out "default-op" causes:
    HPDPZ0028E The configuration file /var/pdweb/webseal-test/etc/webseald-webseal-test.conf is missing the required attribute default-op in stanza oidc.
    --> although the knowledge center state this value is optional: https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.5/com.ibm.isam.doc/wrp_stza_ref/reference/ref_oidc_default_op.html
    Instance can not be started.

    Assigning "default" to "default-op" and providing an empty configuration for "default", causes the instance to not start either.

    Any clarification on this behavior?

    ------------------------------
    Dries Eestermans

    IS4U
    ------------------------------


  • 2.  RE: 9.0.5 - Native OIDC integration

    Posted Thu August 02, 2018 08:31 PM

    Hi Dries,

    After redacting any client_id's and secrets, please send the complete [oidc] related stanzas from your webseal config file.

    I have definitely configured multiple OP's at the same time using the new WebSEAL native OIDC RP, and have had it working.

    Cheers,

    Shane.



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

    Original Message


  • 3.  RE: 9.0.5 - Native OIDC integration

    Posted Fri August 03, 2018 02:41 AM
    Hi Shane,

    Following my Reverse Proxy configuration regarding OIDC auth:
    [oidc]
    oidc-auth = https
    default-op = google

    [oidc:default]
    redirect-uri-host =
    discovery-endpoint =
    proxy =
    client-id =
    response-type = code
    response-mode =
    scopes =
    bearer-token-attributes =
    id-token-attributes =
    allowed-query-arg =
    mapped-identity = {iss}/{sub}
    external-user = true

    [oidc:google]
    redirect-uri-host =
    discovery-endpoint = https://accounts.google.com/.well-known/openid-configuration
    proxy =
    client-id = **obfuscated**
    response-type = code
    response-mode = query
    scopes = profile
    bearer-token-attributes =
    id-token-attributes =
    allowed-query-arg =
    mapped-identity = {iss}/{sub}
    external-user = true
    client-secret = **obfuscated**

    [oidc:is4u]
    redirect-uri-host =
    discovery-endpoint = https://sso-dev.is4u.be/auth/realms/ibm/.well-known/openid-configuration
    proxy =
    client-id = **obfuscated**
    response-type = code
    response-mode = query
    scopes = profile
    bearer-token-attributes =
    id-token-attributes =
    allowed-query-arg =
    mapped-identity = sso-dev.is4u.be/{sub}
    external-user = true
    client-secret = **obfuscated**

    I then add two buttons to the login page:
    ...
    %OIDCAUTHN%
    <hr>
    <form method=GET action="/pkmsoidc">
    <div class="login-inputs">
    <input TYPE="hidden" NAME="iss" VALUE="google">
    <input TYPE="hidden" NAME="token" VALUE="%CREDATTR{tagvalue_session_index}%">
    <input class="submitButton button-1 ease-in-anim-fast" type="submit" value="Google">
    </div>
    </form><hr>
    <form method=GET action="/pkmsoidc">
    <div class="login-inputs">
    <input TYPE="hidden" NAME="iss" VALUE="is4u">
    <input TYPE="hidden" NAME="token" VALUE="%CREDATTR{tagvalue_session_index}%">
    <input class="submitButton button-1 ease-in-anim-fast" type="submit" value="IS4U">
    </div>
    </form>
    ...

    I click on the IS4U button, get a redirect to my OP. Log in, and return with code via url fragment.
    WebSEAL then attempts to exchange code @ Google AS/OP (incorrectly) (taken from pdweb.snoop.oidc):

    (3) 2018-08-03-08:26:03.022 WebSEAL (172.16.99.42:45740) to Client (172.217.15.106:443) Socket opened.

    (3) 2018-08-03-08:26:03.105 WebSEAL (172.16.99.42:45740) to Client (172.217.15.106:443) sending 777 bytes
    POST /oauth2/v4/token HTTP/1.1
    accept: application/json
    authorization: Basic **obfuscated**
    content-length: 441
    content-type: application/x-www-form-urlencoded
    host: www.googleapis.com:443
    ibmclient: isam.wrp

    grant_type=authorization_code&code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.._jR13f2OVoGAcoSJLTwwJg.mR9yS1hVRxpSQEb8wzaUtmmkiMCkDlJPH9fkX78CC12pFLdJwo8iC8u-8vdHEhzQV52jl1PkfKwX3AiBuFXQXebZicp_ycjKGMupLrTOq26bi7OOHSIefCrt7sBgg9v8RkHLwQDbKuQzF0GA529E9Zd1tZD2fLODytaJnLNS48Oi1ShfX-HMHlaVDtFTXN4g_3s-fyjBbrD798Ob-ZByt0CHA6OQlVvjs5NGzLhUn1FtKYBaTImPb7Wn2wgOJq0d.bfY0eFvorAH20dA0PF91lg&redirect_uri=https%3A%2F%2Fibm.oidc.is4u.be%2Fpkmsoidc
    (3) 2018-08-03-08:26:03.226 Client (172.217.15.106:443) to WebSEAL (172.16.99.42:45740) sending 523 bytes
    HTTP/1.1 400 Bad Request
    Vary: X-Origin
    Content-Type: application/json; charset=UTF-8
    Date: Fri, 03 Aug 2018 06:26:03 GMT
    Expires: Fri, 03 Aug 2018 06:26:03 GMT
    Cache-Control: private, max-age=0
    X-Content-Type-Options: nosniff
    X-Frame-Options: SAMEORIGIN
    X-XSS-Protection: 1; mode=block
    Server: GSE
    Alt-Svc: quic=":443"; ma=2592000; v="44,43,39,35"
    Accept-Ranges: none
    Vary: Origin,Accept-Encoding
    Transfer-Encoding: chunked

    4c
    {
    "error": "invalid_grant",
    "error_description": "Malformed auth code."
    }
    (3) 2018-08-03-08:26:03.227 Client (172.217.15.106:443) to WebSEAL (172.16.99.42:45740) sending 5 bytes
    0
    (3) 2018-08-03-08:26:03.227 WebSEAL (172.16.99.42:45740) to Client (172.217.15.106:443) Closing socket.

    Please note the fact that it's actually exchanging my code @ www.googleapis.com, and not IS4U token_endpoint (https://sso-dev.is4u.be/auth/realms/ibm/protocol/openid-connect/token).

    I hope this clarifies the setup.

    ​​

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------

    Original Message


  • 4.  RE: 9.0.5 - Native OIDC integration

    Posted Fri August 03, 2018 04:14 AM
    Try these things:

    1. Capture the complete URLs *at the browser* during this flow and include that information here. Specifically I want to see what parameters are sent in the original redirect to the OP, including the redirect_uri, and what is coming back from the OP (again as seen at the browser). This is critical to trying to spot what might be wrong.

    2. Remove the response_mode setting from your [oidc:is4u] configuration. HTTP GET is the default for the authorization code flow, and you shouldn't need it. This eliminates a possible point of confusion.

    3. Try different settings for:
    [oidc]
    default-op = <different_values_here>
    Try values of "default", and "is4u". The goal is to see if the "default-op" is erroneously being used to choose the token endpoint to use when you arrive back at ISAM with the code from the OP.

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

    Original Message


  • 5.  RE: 9.0.5 - Native OIDC integration

    Posted Fri August 03, 2018 05:31 AM
    Hi Shane,

    I performed the following:
    Removed response_mode = query from both RPs (Google & IS4U).

    Change default-op to "default". --> instance does not restart.
    Change default-op to "is4u". --> instance starts

    With default-op changed to "is4u", code is exchanged at IS4U Token Endpoint. WebSEAL however fails to create an authenticated session since (I think) my ID token is missing the "at_hash" attribute:
    2018-08-03-11:13:40.810+02:00I----- 0x3898342B webseald ERROR wad general OIDCOpClient.cpp 680 0x7f07d2fbc700 -- DPWAD1067E The element, at_hash, was not found in the JSON data.

    (3) 2018-08-03-11:19:03.983 WebSEAL (172.16.99.42:38538) to Client (91.121.219.188:443) Socket opened.

    (3) 2018-08-03-11:19:04.001 WebSEAL (172.16.99.42:38538) to Client (91.121.219.188:443) sending 744 bytes
    POST /auth/realms/ibm/protocol/openid-connect/token HTTP/1.1
    accept: application/json
    authorization: Basic **obfuscated**
    content-length: 441
    content-type: application/x-www-form-urlencoded
    host: sso-dev.is4u.be:443
    ibmclient: isam.wrp

    grant_type=authorization_code&code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..LeQqtqsDR6jKFwGD0KgUTQ.lozjxXknaeMfwxVte3B3dNLjpf1DaEj7Ujy0hPVzV2iQmdZ7S4xcQarVkLBZgoOMssvAOZILtGhIXT8J_pDai62xqmebR3mXnIlyx9HSm2KE7GmPAR7qTCvlMn4hueCfUN1DM7E1eC9Cm73SvgKM4Y-xAl1ZrN2o5ezGaZW8k324dicdYpTJ6r8TQRQ9PPkcqbFPVRUer3Qfx0NinxPmZG2FcGry3GjD7BFczA1oWoRPxElg4aplCB9u4Y-L9i5X.Vzb_gw4GltSjQFkCWoUvhQ&redirect_uri=https%3A%2F%2Fibm.oidc.is4u.be%2Fpkmsoidc
    (3) 2018-08-03-11:19:04.008 Client (91.121.219.188:443) to WebSEAL (172.16.99.42:38538) sending 4192 bytes
    HTTP/1.1 200 OK
    Connection: keep-alive
    Content-Type: application/json
    Content-Length: 4058
    Date: Fri, 03 Aug 2018 09:19:04 GMT

    {"access_token":"**access_token**","expires_in":300,"refresh_expires_in":1800,"refresh_token":"**refresh_token**","token_type":"bearer","id_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJZM1RqVTRoUHFOU0hpRUwtcERFeTNTYUpJOWZVcm9ocmh6R1lKOXkyLTFRIn0.eyJqdGkiOiI2N2FlOWQxMS0zNGFmLTRlOTktYTA1NS02NThlYzc0OTFmYmMiLCJleHAiOjE1MzMyODgyNDQsIm5iZiI6MCwiaWF0IjoxNTMzMjg3OTQ0LCJpc3MiOiJodHRwczovL3Nzby1kZXYuaXM0dS5iZS9hdXRoL3JlYWxtcy9pYm0iLCJhdWQiOiJpYm0ub2lkYy5pczR1LmJlIiwic3ViIjoiMDJjZjU3ZTAtNzA2Ny00YzEwLThhZTItY2I4ZWQ3M2JhZTIwIiwidHlwIjoiSUQiLCJhenAiOiJpYm0ub2lkYy5pczR1LmJlIiwibm9uY2UiOiJjNWZmNjk4MC05NGY4LWRlM2MtODA4MC1mMzRjMzVmM2YxYzciLCJhdXRoX3RpbWUiOjE1MzMyODc5NDMsInNlc3Npb25fc3RhdGUiOiJmMDc2ZGQ2MS1hODZmLTQzYTYtYTdiYy0yMmYzYzQ3N2ZmZTEiLCJhY3IiOiIxIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsIm5hbWUiOiJkZW1vIHVzZXIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJkZW1vdXNlciIsImdpdmVuX25hbWUiOiJkZW1vIiwiZmFtaWx5X25hbWUiOiJ1c2VyIiwiZW1haWwiOiJkcmllcy5lZXN0ZXJtYW5zQGlzNHUuYmUifQ.E7Be6TxrrbERjsV-3Mec7EdR58dExQqV_b7pyHA1iWRcleGaY6Nd0QFbXUA7Yg6t-dcseCv_8ITjjwpfdKzJLLEDowURbDXNDKEezO6Ki7dyTgt8RB8hTp4GCQchQ0Ichabz8XMbdha5KUgUxUkrkwn8WFSYGWyL32rfDr6WimBWIdtPTv97mZTZeBp2MYCPV-PwgAWyEInEzwauq3X-V3CAPKBU-N34Bt1EK0r-S1_7tEcyt_oKXlMHlvNV3ZEkq48IefGTLQVVZ1X9Clgxfibm1DpDQ9DsLjxG6_O7ZCP5l2aHP9krM2AXZx1VC8zErWGUJZH1CP5QeNKoCJpOEw","not-before-policy":0,"session_state":"f076dd61-a86f-43a6-a7bc-22f3c477ffe1","scope":"openid profile email"}
    (3) 2018-08-03-11:19:04.008 WebSEAL (172.16.99.42:38538) to Client (91.121.219.188:443) Closing socket.

    ID Token is indeed missing the "at_hash" attribute, but according to OIDC spec, this is optional? http://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken.
    But that's a different issue.

    Google authentication is no longer possible, since it's exchanging code @ IS4U token endpoint (= default-op):
    2018-08-03-11:15:58.674+02:00I----- 0x38983428 webseald ERROR wad general OIDCOpClient.cpp 344 0x7f07d2e77700 -- DPWAD1064E An invalid HTTP status code, 400, was received in response to a request sent to https://sso-dev.is4u.be:443/auth/realms/ibm/protocol/openid-connect/token

    As you can see it's defaulting to the "default-op".
    The Google OP sends a redirect:
    Response:
    ...
    location: https://ibm.oidc.is4u.be/pkmsoidc?state=30bdd816-5dd5-a484-805e-82080a24d023%3Agoogle&code=4%2FMABj81jrk_a6OGsZeJf8kaP3mFX5-R7YChV3n79glyWFxjBoGTKETldcYYLlDhoHeytCELL2zsVTV3NG2B2bdpM&authuser=0&session_state=1491119f52c85f6ff60f18ea81334e0e7d5b15f7..f358&prompt=none#
    ...

    Then my browser performs the GET request on the pkmsoidc endpoint:
    fetch("https://ibm.oidc.is4u.be/pkmsoidc?state=30bdd816-5dd5-a484-805e-82080a24d023%3Agoogle&code=4%2FMABj81jrk_a6OGsZeJf8kaP3mFX5-R7YChV3n79glyWFxjBoGTKETldcYYLlDhoHeytCELL2zsVTV3NG2B2bdpM&authuser=0&session_state=1491119f52c85f6ff60f18ea81334e0e7d5b15f7..f358&prompt=none", {"credentials":"include","headers":{},"referrer":"https://accounts.google.be/accounts/SetSID","referrerPolicy":"no-referrer-when-downgrade","body":null,"method":"GET","mode":"cors"});

    Yet, code will be exchanged @ default-op.

    If you need any more information, let me know!

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------

    Original Message


  • 6.  RE: 9.0.5 - Native OIDC integration

    Posted Fri August 03, 2018 08:33 AM
    This is very odd. I have an ISAM 905 system with two OP's configured and do not see that behaviour at all. Please open a case with support, and in the meantime I'll try to reproduce locally.

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

    Original Message


Related Content