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
Back to discussions
Expand all | Collapse all

Testing OpenID Connect

  • 1.  Testing OpenID Connect

    Posted Tue October 06, 2020 12:00 PM
    Edited by Joao Goncalves Tue October 06, 2020 12:44 PM
    I am using the scripts provided in IBM-Security/isam-support for testing OpenID Connect, and I am getting an error which I cannot understand what is going on!

    I created a user, named oiduser which I can successfully login using pkmslogin.form
    The OpenID configuration, on the Grant Type I only selected Authorization code.

    The OIDC client is configured this way:

    I generated the Reverse Proxy Junction /mga:

    When I try to test this connection using oauth-authorization-grant.sh I get this error message:
    + HOST=169.254.253.131
    + CLIENT_ID=ClientApp
    + CLIENT_SECRET=secret
    + USER=oiduser
    + PASSWORD=P@ssw0rd
    + rm -f cookie.jar
    + ./pkmslogin.sh 169.254.253.131 oiduser P@ssw0rd
    ++ ./get-authorize.sh 169.254.253.131 ClientApp secret
    ++ awk -F= '{print $2}'
    + HOST=169.254.253.131
    + CLIENT_ID=ClientApp
    + CLIENT_SECRET=secret
    + curl -v -s -k --cookie cookie.jar --cookie-jar cookie.jar 'https://169.254.253.131/mga/sps/oauth/oauth2/authorize?response_type=code&client_id=ClientApp&client_secret=secret'
    + grep location
    + AUTHORIZATION_CODE=' self.location;
    '\''ISAMOriginalURL'
    + ./get-token.sh 169.254.253.131 ClientApp secret 'self.location;' ''\''ISAMOriginalURL'
    + HOST=169.254.253.131
    + CLIENT_ID=ClientApp
    + CLIENT_SECRET=secret
    + CODE='self.location;'
    + curl -s -k -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept: text/html' -d 'grant_type=authorization_code&code=self.location;&client_id=ClientApp&client_secret=secret&redirect_uri=&response_type=code' https://169.254.253.131/mga/sps/oauth/oauth20/token
    {"error_description":"FBTOAU211E The [authorization_grant] received of type [authorization_code] does not exist.","error":"invalid_grant"}+ exit 0
    + exit 0



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


  • 2.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 12:39 PM
    Edited by Joao Goncalves Tue October 06, 2020 12:55 PM
    I noticed that in the get-authorize.sh script there is a missing parameter, scope. According to the authorize endpoint definition (https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.7/com.ibm.isam.doc/config/concept/con_oidc_op_auth_point.html) this parameter is required.
    But even after changing the script, it didn't work.
    Here is the updated script:

    #! /bin/sh
    HOST=$1
    CLIENT_ID=$2
    CLIENT_SECRET=$3

    curl -v -s -k --cookie cookie.jar --cookie-jar cookie.jar \
    "https://$HOST/mga/sps/oauth/oauth2/authorize?response_type=code&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=openid" 2>&1 | tee authorize.out | grep location

    ​I went to check the reverse proxy logs, and found this:
    40 169.254.253.29 - oiduser 06/Oct/2020:16:49:10 +0100 "GET /pkmslogin.form HTTP/1.1" 200 8683
    41 169.254.253.29 - unauthenticated 06/Oct/2020:16:58:42 +0100 "GET /mga/sps/oauth/oauth2/authorize?response_type=code&client_id=ClientApp&client_secret=secret HTTP/1.1" 200 13516
    42 169.254.253.29 - unauthenticated 06/Oct/2020:16:58:43 +0100 "POST /mga/sps/oauth/oauth20/token HTTP/1.1" 400 138

    Although authorize return "200", curl apparently did not use the sessionID, as the request was not identified to "oiduser".
    Am I thinking correctly?

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

    Original Message


  • 3.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 02:07 PM
    Hi Joao,

    The scope=openid is required by OpenID Connect.  I guess it's not included in the scripts you're using because they are for OAuth which doesn't have that requirement.  I don't know if it's relevant but when doing OpenID Connect, the Redirect URI is required in the request to /authorize and must match a configured redirect URI on the client definition.  Again, this isn't required for OAuth.

    I'm not sure that is the root cause of your issue though - I think you're probably right that the "unauthenticated" request to /authorize is more of a problem.

    I'm not an expert on cURL but I think that after the pkmslogin script has completed, there should be a PD_S_SESSION_ID cookie in the cookie.jar file.  This should allow the authorize script to be authenticated.  Does the response from pkmslogin indicate a successful login?  (A 200 doesn't necessarily mean it worked - you need to see a success message in the response body).  Do you see the cookie.jar file get created successfully?

    Jon.

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

    Original Message


  • 4.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 02:09 PM
    P.S. Maybe remove the > /dev/null from the call to pkmslogin.sh in the main script - so you can see the output.

    Jon.

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

    Original Message


  • 5.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 02:45 PM
    Edited by Joao Goncalves Tue October 06, 2020 02:48 PM
    I actually found another error, but after fixing it, it didn't solve this problem.

    After fixing this, I get something different on the reverse proxy logs, which shows an improvement, but now getting an 403 on the authorize endpoint (could be the Redirect URL, that I'm going to fix next):
    64 169.254.253.29 - oiduser 06/Oct/2020:19:36:09 +0100 "POST /pkmslogin.form?token=Unknown HTTP/1.1" 200 8015
    65 169.254.253.29 - oiduser 06/Oct/2020:19:36:09 +0100 "GET /mga/sps/oauth/oauth2/authorize?response_type=code&client_id=ClientApp&client_secret=secret&scope=openid HTTP/1.1" 403 2039
    66 169.254.253.29 - unauthenticated 06/Oct/2020:19:36:09 +0100 "POST /mga/sps/oauth/oauth20/token HTTP/1.1" 400 121

    Here is the output of pkmslogin:
    + HOST=169.254.253.131
    + USER=oiduser
    + PASS=P@ssw0rd
    + curl -v -s -k --cookie-jar cookie.jar --cookie cookie.jar -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://169.254.253.131/pkmslogin.form?token=Unknown' --data-ascii 'username=oiduser&password=P@ssw0rd&login-form-type=pwd'
    * About to connect() to 169.254.253.131 port 443 (#0)
    * Trying 169.254.253.131...
    * Connected to 169.254.253.131 (169.254.253.131) port 443 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    * skipping SSL peer certificate verification
    * SSL connection using TLS_RSA_WITH_AES_128_GCM_SHA256
    * Server certificate:
    * subject: CN=isam.pyxis.pt
    * start date: Sep 26 19:52:00 2020 GMT
    * expire date: Oct 12 19:52:00 2040 GMT
    * common name: isam.pyxis.pt
    * issuer: CN=isam.pyxis.pt
    > POST /pkmslogin.form?token=Unknown HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: 169.254.253.131
    > Accept: */*
    > Content-Type: application/x-www-form-urlencoded
    > Content-Length: 54
    >
    } [data not shown]
    * upload completely sent off: 54 out of 54 bytes
    < HTTP/1.1 200 OK
    < content-length: 8015
    < content-type: text/html
    < date: Tue, 06 Oct 2020 18:36:09 GMT
    < p3p: CP="NON CUR OTPi OUR NOR UNI"
    < server: WebSEAL/9.0.7.0
    < x-frame-options: DENY
    < x-content-type-options: nosniff
    < cache-control: no-store
    < x-xss-protection: 1
    < content-security-policy: frame-ancestors 'none'
    < strict-transport-security: max-age=31536000; includeSubDomains
    < pragma: no-cache
    * Added cookie PD-S-SESSION-ID="1_2_1_xYaVA3F2lv0+8WyHaNtMwyZPG3PWbxEXAZKyD-q27X
    tRH3ps" for domain 169.254.253.131, path /, expire 0
    < Set-Cookie: PD-S-SESSION-ID=1_2_1_xYaVA3F2lv0+8WyHaNtMwyZPG3PWbxEXAZKyD-q27XtR
    H3ps; Path=/; Secure; HttpOnly
    <
    { [data not shown]
    <!DOCTYPE html>
    <!-- Copyright (C) 2015 IBM Corporation -->
    <!-- Copyright (C) 2000 Tivoli Systems, Inc. -->
    <!-- Copyright (C) 1999 IBM Corporation -->
    <!-- Copyright (C) 1998 Dascom, Inc. -->
    <!-- All Rights Reserved. -->
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>IBM Security Access Manager</title>
     <style>

    em {
    font-style:inherit;
    font-weight:700;
    }

    body {
    background-color:#555;
    font-family:Helvetica, Arial, sans-serif;
    -moz-font-smoothing:antialiased;
    -ms-font-smoothing:antialiased;
    -o-font-smoothing:antialiased;
    unicode-bidi:embed;
    -webkit-font-smoothing:antialiased;
    -webkit-locale:en;
    margin:0;
    padding:0;
    }

    html {
    height:100%;
    min-height:400px;
    ...



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

    Original Message


  • 6.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 02:47 PM
    Edited by Joao Goncalves Tue October 06, 2020 03:08 PM
    I'm going to try to get the Redirect URL fixed, and see if this works. I'll show you the result.
    But according to the documentation (https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.6/com.ibm.isam.doc/config/concept/con_oidc_op_auth_point.html), Redirect_uri is optional, not required.

    The Cookie is in fact named PD-S-SESSION-ID.

    Here is the page I got with or without the redirect_uri option. It is obvious that I didn't get the authorization code, which invalidates obtaining the access token.



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


  • 7.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 03:38 PM
    After fixing further problems, here is what I found:
    • According to the documentation, redirect_uri and state are optional, but indeed, they are mandatory
    • Using the provided scripts, there is a missing step to complete the process:
      • After the authorize, the user is prompted to accept the relying partner to access the resources, to which we have to permit
      • Only after this step, we get the Authentication Code, that can be used to obtain the Access token

    I have not yet tested the script to get access token. I will try to write the missing script and make it available for the community.

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

    Original Message


  • 8.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 03:47 PM

    Hi Joao,

    The difference in optional vs mandatory is the difference between "raw" OAuth and OIDC. Since you have enabled your definition for OIDC, Verify Access is enforcing the extra requirements.

    The extra step for consent is based on a configuration option in the definition - can't remember the name - you should be able to turn it off if you want to.

    If you're able to adapt the scripts to work with OIDC then that would be great. Thanks.

    Jon. 



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

    Original Message


  • 9.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 06:06 PM
    Done.
    The scripts are working fine for me. I will post each one in a different reply posts

    #!/bin/sh
    [ "$DEBUG" ] && set -x

    HOST=$1
    USER=$2
    PASS=$3

    curl -v -s -k --cookie-jar cookie.jar --cookie cookie.jar \
    -H 'Content-Type: application/x-www-form-urlencoded' \
    -X POST https://$HOST/pkmslogin.form?token=Unknown \
    --data-ascii "username=$USER&password=$PASS&login-form-type=pwd"

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

    Original Message


  • 10.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 06:09 PM
    Edited by Joao Goncalves Tue October 06, 2020 06:22 PM
    Second Script:
    get-authorize.sh
    #! /bin/sh
    # authorize.sh to validate authorize request and response

    [ "$DEBUG" ] && set -x

    HOST=$1
    CLIENT_ID=$2
    CLIENT_SECRET=$3
    REDIRECT_URI=$4

    curl -v -s -k --cookie cookie.jar --cookie-jar cookie.jar \
    "https://$HOST/mga/sps/oauth/oauth20/authorize?response_type=code&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=openid&state=none&redirect_uri=$REDIRECT_URI" > authorize.out.1 2>&1

    CONSENT=`grep consent_form_verifier authorize.out.1 | sed 's/.*value=\"\(.*\)\".*/\1/'`
    echo consent_form_verifier: $CONSENT > oauth.out

    curl -v -s -k --cookie cookie.jar --cookie-jar cookie.jar \
    -X POST \
    "https://$HOST//mga/sps/oauth/oauth20/authorize" \
    --data-ascii "client_secret=$CLIENT_SECRET&scope=openid&consent_form_verifier=$CONSENT&trust_level=permit" > authorize.out.2 2>&1
    grep location authorize.out.2

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

    Original Message


  • 11.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 06:10 PM
    Third script:
    get-token.sh

    #!/bin/sh
    [ "$DEBUG" ] && set -x

    HOST=$1
    CLIENT_ID=$2
    CLIENT_SECRET=$3
    CODE=$4
    REDIRECT_URI=$5

    curl -s -k -H 'Content-Type: application/x-www-form-urlencoded' \
    -H 'Accept: text/html' \
    -d "grant_type=authorization_code&code=$CODE&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&redirect_uri=$REDIRECT_URI&response_type=code" \
    https://$HOST/mga/sps/oauth/oauth20/token > token.out 2>&1

    echo Access Token: >> oauth.out
    cat token.out >> oauth.out
    exit $?

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

    Original Message


  • 12.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 06:12 PM
    Edited by Joao Goncalves Tue October 06, 2020 06:19 PM
    Fourth Script: (recommendation: if you run these scripts multiple times, you should set "Always prompt" on the OpendID provider options)

    oauth-authorization-grant.sh

    #! /bin/sh
    [ "$DEBUG" ] && set -x

    HOST=$1
    CLIENT_ID=$2
    CLIENT_SECRET=$3
    USER=$4
    PASSWORD=$5
    REDIRECT_URI=$6

    rm -f cookie.jar

    ./pkmslogin.sh "$HOST" "$USER" "$PASSWORD" > pkmslogin.out 2>&1

    AUTHORIZATION_CODE=`./get-authorize.sh "$HOST" "$CLIENT_ID" "$CLIENT_SECRET" "$REDIRECT_URI" | sed 's/.*code=\(.*\)/\1/'`
    echo authorization code: $AUTHORIZATION_CODE >> oauth.out
    ./get-token.sh "$HOST" "$CLIENT_ID" "$CLIENT_SECRET" $AUTHORIZATION_CODE "$REDIRECT_URI"

    exit $?

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

    Original Message


  • 13.  RE: Testing OpenID Connect

    Posted Tue October 06, 2020 06:16 PM
    Something else I noticed, is that the id_token does not include any user attributes other than the standard ones:
    {
    "rt_hash": "",
    "iat": ,
    "iss": "",
    "at_hash": "",
    "sub": "",
    "exp": ,
    "aud": ""
    }

    which means, I believe, that if you need any other attributes, you need to add them explicitly. This behaviour is different from what happens in SAML.
    You usually need information like the groups you belong to, and so on...


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

    Original Message


  • 14.  RE: Testing OpenID Connect

    Posted Wed October 07, 2020 07:12 AM
    Hi Joao,

    Thanks for the updated scripts.  I can see you've added in support for consent and for the parameters that are mandatory in OIDC.

    @Nick Lloyd - maybe these could be added to the IBM-Security GitHub as alternative scripts for working with OIDC vs OAuth?

    Jon.
    ​

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

    Original Message


  • 15.  RE: Testing OpenID Connect

    Posted Wed October 07, 2020 09:02 AM
    I have different scripts for OAUTH vs. OIDC just do not have them checked in yet.  I can take Joao's change as well and get them organized.

    ------------------------------
    Nick
    IBM Security Verify Customer Support
    ------------------------------

    Original Message


  • 16.  RE: Testing OpenID Connect

    Posted Wed October 07, 2020 07:37 AM
    Hi Joao,

    With OpenID Connect you don't get any attributes without asking for them and (optional) user consent.

    For main identity attributes, you ask by requesting scopes like this:

    openid - required (as you found)
    profile - basic name information
    email - user's email address

    Group memberships are not included in this set of attributes (OIDC has more focus on identity that authorization) and "groups" is not a scope defined by the specification.

    As an OIDC Relying Party, you can request additional attributes from a Provider by adding custom claim to your OIDC Request.  If you add a claim requesting a standard Verify Access credential attribute it will be returned.  If you want to tie this to custom scopes, or return claims regardless of request, that would require custom coding in the pre- and post- token mapping rules.

    I hope this points you in the right direction.  Have a look at this course too:
    https://www.securitylearningacademy.com/course/view.php?id=3307

    I also added a lab guide I wrote for ISAM 9.0.6.0 which might be interesting.  I covers how to request additional attributes with claims (the authentication mechanisms in this case but could be applied to groups too).
    https://community.ibm.com/community/user/security/viewdocument/openid-connect-guide-9060?CommunityKey=e7c36119-46d7-42f2-97a9-b44f0cc89c6d&tab=librarydocuments

    Jon.

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

    Original Message


  • 17.  RE: Testing OpenID Connect

    Posted Wed October 07, 2020 03:40 PM
    Thanks for the information, but I already had those sources. Nevertheless, I went and read them all over again, making sure I didn't miss anything.

    I have a comment though. In the lab guide for ISAM 9.0.7, in section 4.4, you added OIDC OP as a Federated Partner, but in the configuration I did in my test environment I never did this. Instead, I added the junction /mga by selecting Secure Web Settings -> Manage -> Reverse Proxy.
    After selecting the reverse proxy, I used Manage -> AAC and Federation Configuration -> OAuth and OpenID Connect Provider Configuration instead of what you did!

    What is the difference? Does it matter the way you configure it?

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

    Original Message


  • 18.  RE: Testing OpenID Connect

    Posted Thu October 08, 2020 05:58 AM
    Hi Joao,

    If you set up the system as a Relying Party they you must have completed section 4.4 because it wouldn't work without defining the OIDC Provider to the Relying Party.  Perhaps in your environment you only configured the system as an OIDC Provider?

    The Manage -> AAC and Federation Configuration -> OAuth and OpenID Connect Provider Configuration step that you mention is a step required when setting up an OIDC Provider and is not really related to the configuration of an OIDC Relying Party  - so it doesn't make sense to compare these two things.

    Jon

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

    Original Message


  • 19.  RE: Testing OpenID Connect

    Posted Thu October 08, 2020 06:49 AM
    In fact I created also a relying partner which is working fine.
    It was my bad. You are right, I just miss read the document.

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

    Original Message