Gluu CN Test scenarios - GluuFederation/cloud-native-edition GitHub Wiki

There needs to be a way to test almost all - if not all - scenarios that are possible with Cloud Native Gluu Server. Described below are all Gluu Server services, all possible scenarios for each, test paths and their expected or non-expected results.

Cache Refresh

Expected results

Successful login using external database both with 2FA and with simple authentication

steps

Enable cr-rotate during deployment
Request access token from authorization server
Authenticate the request with client credentials
Navigate to Configuration --> other custom scripts
Under Cache Refresh TAB enable cache_refresh script then hit update
Navigate to Configuration --> Cache Refresh
Select Source Backend ldap Servers TAB hit add source ldap server button
Add a source server named source with bindDn cn=directory manager,o=gluu with maxCon 1000 with servers <ldap-server-ip>:1636 with baseDns o=gluu;o=site using ssl true
change the bind dn password to <ldap-bind-dn-pass>
Test the connection
- if connection is okay, proceed to other configurations
Under the tab named 'Customer Backend Key/Attributes'
Add a key attribute named 'SAMAccountname'
Add object classes for the source ldap server.
- Add an object class named top
- Add an object class named person
- Add an object class named organizationalPerson
- Add an object class named user
Add source attributes of the source ldap server
- Add source attribute named mail
- Add source attribute named displayName
- Add source attribute named cn
- Add source attribute named sn
Under tab named 'Cache Refresh`
Map/Add source attributes to destination attributes. i.e <external-ldap-server> : <gluu-ldap-server>
- SAMAccountname : uid
- top : top
- cn : cn
- sn : sn
- mail : mail
- displayName : displayName
Set polling interval to 2
Set Gluu Server IP Address
Enable Keep external persons
Enable Cache refresh
Update

Testing twilio sms authentication script

Navigate to Configuration-->Person Authentication Scripts
Under twilio_sms add Twillio configurations
- add twilio_sid, twilio_token, from_number
- Enable twillio sms script and update
Navigate to Configuration-->Manage Authentication
Under Default Authentication Method TAB
- Set authentication mode to twilio_sms
- Set oxTrust authentication mode to twilio_sms and update
Logout
Authenticate with twilio sms OTP

Possible points of failure

Use of Wrong Twilio configurations' value will result in authentication failure

Test paths

Coming up

References

OXAUTH

Responsible for authentication.

Expected results

Successful authentication returns an access token
Steps:
- Request access token from authorization server
- Authenticate the request with client credentials

Posible points of failure:

Wrong username
wrong password
Using an invalid session id e.g Failed to get session by id: e702fa38-c8f9-452e-873a-54542135b40b

Test paths:

Coming up...

OXTRUST API

Offers REST APIs for the oxtrust admin GUI
Has 2 modes. Test Mode and UMA Mode

Test Mode

Expected Results.

Make a request to one of the 'oxtrust' API endpoint using an access token from a valid authentication.

   curl -k -H 'Authorization: Bearer 1876f355-2366-4ac3-b9ee-f224606ed26b' \
    https://demoexample.gluu.org/identity/restv1/api/v1/groups

And the response should be

   [
    {
        "status": "ACTIVE",
        "displayName": "Gluu Manager Group",
        "description": "This group is for administrative purpose, with full acces to users",
        "members": [
            "inum=04f0d0e9-a609-4a0a-9580-ebd981a49a61,ou=people,o=gluu"
        ],
        "inum": "60B7",
        "owner": null,
        "organization": null,
        "iname": null
    }
   ]

Steps

Enable Test Mode feature in oxtrust UI by:
- Enable oxtrust_api_access_policy by navigating to Configuration > Other Custom Scripts under the TAB UMA RPT Policies
- Set oxTrustApiTestMode to true by navigating to Configuration > oxTrust Configuration TAB set form field name oxTrustApiTestMode to true
Obtain Test mode client credentials from gluu ConfigMap and Secret objects.
- api_test_client_id

➜  Gluu Federation~: kubectl -n default get cm gluu -o yaml | grep api_test_client_id

  api_test_client_id: 0008-b30eee0f-b83e-40b0-bf43-899429f80889

api_test_client_secret

➜  Gluu Federation~: kubectl get secret -o yaml | grep api_test_client_secret

    api_test_client_secret: b2JHMVNGOWNRVFpQM2xVb0NRYWRYZ3ZT
          f:api_test_client_secret: {}

Make sure to decode the value in secret object
Use the credentials to authenticate and get a token from Gluu server

curl -k -u '0008-b30eee0f-b83e-40b0-bf43-899429f80889:b2JHMVNGOWNRVFpQM2xVb0NRYWRYZ3ZT' \
    https://demoexample.gluu.org/oxauth/restv1/token \
    -d grant_type=client_credentials

If the request is valid the response should be,

{
    "access_token": "0d14102c-70e5-485c-8b64-e56f1ecfcf3e",
    "token_type": "bearer",
    "expires_in": 299
}

Possible points of failure

Using invalid URL
- response: 404
Using invalid api_test_client_id
Using invalid api_test_client_secret
Error message when these are encountered

    {
    "error_description": "Client authentication failed (e.g. unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client.",
    "error": "invalid_client"
}

If the client attempted to authenticate via the Authorization request header field.
- response: the authorization server MUST respond with an HTTP 401

Test Paths

Coming up...

UMA Mode

Expected results.

Successful retrieval of groups using the API endpoint and the generated token.

request

curl -k -H 'Authorization: Bearer d01cdc70-6519-4118-89bb-9ee1748acdd1_D8F4.E104.D094.6B62.79E0.6F8E.FB55.0509' \
    https://demoexample.gluu.org/identity/restv1/api/v1/groups

response

[
    {
        "status": "ACTIVE",
        "displayName": "Gluu Manager Group",
        "description": "This group is for administrative purpose, with full acces to users",
        "members": [
            "inum=04f0d0e9-a609-4a0a-9580-ebd981a49a61,ou=people,o=gluu"
        ],
        "inum": "60B7",
        "owner": null,
        "organization": null,
        "iname": null
    }
]

Steps

First step of Test Mode applies here - Enabling via UI.
Make a request to oxTrust API
- curl -k -I https://demoexample.gluu.org/identity/restv1/api/v1/groups
- Expected result: Request rejected
  output:
```
 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: UMA realm="Authorization required", host_id=demoexample.gluu.org, as_uri=https://demoexample.gluu.org/.well-known/uma2-configuration, ticket=ed5d9fa7-7117-4fc0-85c2-17a064448dc8
```
- Extract the ticket from WWW-Authenticate header. ticket=ed5d9fa7-7117-4fc0-85c2-17a064448dc8
Copy api-rp.jks and api-rp-keys.json from oxAuth container to a json file.
- get oxauth pod name and copy the files in the host

POD=$(kubectl get po -l APP_NAME=oxauth -o jsonpath="{.items[0].metadata.name}")
kubectl cp $POD:etc/certs/api-rp.jks api-rp.jks && kubectl cp rp-oxauth-6c8ccb4ff6-hmm2l:etc/certs/api-rp-keys.json api-rp-keys.json

Grab the kid of the key value whose algorithm - alg - value is RS256. We can use jq here

{
    "keys": [
        {
            "kty": "RSA",
            "e": "AQAB",
            "use": "sig",
            "crv": "",
            "kid": "777c0619-802c-480d-9432-a5e25f85867a_sig_rs256",
            "x5c": ["MIIDAzCCAeugAwIBAgIgIoDkhKXYZG5/LDPoUEUBxLpvsUDwL+OEzkAMuMpglzLH6g9dDUyGVEh8iRg=="],
            "exp": 1606219942910,
            "alg": "RS256",
            "n": "r3LItabzy3Lg0SXf_6EZ1oANjyYQ_HCEj-r5cynyD7dnAQdXvkRLVMAby0EAoCaeEo_QkU79BCOY6o2w"
        }
    ]
}

Get the keystore password from k8s Secret object

➜  Gluu Federation kubectl get secret -o yaml | grep api_rp_client_jks_pass
    api_rp_client_jks_pass: NExhUWpacUdra1pJ

Delete api-rp.pkcs12 if exits
Convert api-rp.jks to api-rp.pkcs12

keytool -importkeystore \
    -srckeystore api-rp.jks \
    -srcstorepass secret  \
    -srckeypass secret \
    -srcalias 777c0619-802c-480d-9432-a5e25f85867a_sig_rs256 \   -----> kid
    -destalias 777c0619-802c-480d-9432-a5e25f85867a_sig_rs256 \  -----> kid
    -destkeystore api-rp.pkcs12 \
    -deststoretype PKCS12 \
    -deststorepass secret \
    -destkeypass secret

Extract private key pair from api-rp.pkcs12.

openssl pkcs12 -in api-rp.pkcs12 -nodes -out api-rp.pem -passin pass:secret

Prepare data for genrating JWT string
- header

{
    "typ": "JWT",
    "alg": "RS256",
    "kid": "777c0619-802c-480d-9432-a5e25f85867a_sig_rs256"
}

payload: Get client id from config backend using the key oxtrust_requesting_party_client_id

➜  Gluu Federation ~ kubectl get cm gluu -o yaml | grep oxtrust_requesting_party_client_id
  oxtrust_requesting_party_client_id: 1402.46176650-640f-487d-a056-daea8539f027

Create the payload Since jti value below must be unique, it can be generated using uuidgen

{
    "iss": "0008-76f0b100-6d68-4f21-96ca-c6e49d30094b",
    "sub": "0008-76f0b100-6d68-4f21-96ca-c6e49d30094b",
    "exp": 1575185573,
    "iat": 1575181565,
    "jti": "2f1c50c6-0359-4913-b3f9-c17ca93a1b82",
    "aud": "https://demoexample.gluu.org/oxauth/restv1/token"
}

Use the header, payload and private key extracted previously to generate a JWT string.
Use the JWT to get token from https://demoexample.gluu.org/oxauth/restv1/token

curl -k https://demoexample.gluu.org/oxauth/restv1/token \
    -d grant_type='urn:ietf:params:oauth:grant-type:uma-ticket' \
    -d ticket='ed5d9fa7-7117-4fc0-85c2-17a064448dc8'  \
    -d client_id='0008-76f0b100-6d68-4f21-96ca-c6e49d30094b' \
    -d client_assertion_type='urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
    -d client_assertion='eyJhbGciOiJSUzI1NiIs.RiLZyW2yYdF4P0QD0oY9zjBfsFwFSpSCRUe.3WnaETMtAIPpXQhry6SYFR1tFv1t4XO14o1qVA' ---->>> JWT string
    -d scope=`oxtrust-api-read oxtrust-api-write`

Successful response should look like below:-

{
    "access_token": "d01cdc70-6519-4118-89bb-9ee1748acdd1_D8F4.E104.D094.6B62.79E0.6F8E.FB55.0509",
    "token_type": "Bearer",
    "upgraded": false,
    "pct": "0b598193-11cb-4926-9e4c-cc7c95e6ce37_CB14.8C6B.E2B2.46CD.53B2.CBEF.C50E.9FE9"
}

Use the access_token to request for a resource. e.g As is in expected results

Test Paths

Most of the test paths can be found oxtrust-api references link

References.

Oxtrust API guide

SCIM

Expected results

Send successful requests to SCIM endpoints.
- Using the user details below to create a new user.

input.json

{
    "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName":"ajsmith",
    "name":{
        "familyName":"Smith",
        "givenName":"Joe"
    },
    "displayName":"Average Joe"
}

Sending a request to SCIM user endpoint /identity/restv1/scim/v2/Users to create the above user

$ curl -H 'Authorization: Bearer ...access token...' -H 'Content-Type: application/scim+json'
  -d @input.json -o output.json https://demoexample.gluu.org/identity/restv1/scim/v2/Users

Successful request will have the response shown below in output.json file

{
  "id": "...",
  "meta": {
    "created": "...",
    "lastModified": "...",
    "location": "https://.../scim/v2/Users/@!..."
    "resourceType": "User"
  },
  "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User" ],
  "userName": "ajsmith",
  "name": {
    "formatted": "Joe Smith",
    "familyName": "Smith",
    "givenName": "Joe"
  },
  "displayName": "Average Joe",
  ...
}

steps

Protect SCIM endpoints
- Using UMA
  - Navigate to Configuration --> Organization Configuration and enable Scim support and click Update button
  - Enable UMA protection mode in Configuration --> Other Custom Scripts under UMA RPT policies TAB enable the scim_access_policy script
- Using Test mode
  - Enable Scim support
  - Enable Test mode protection in Configuration --> JSON Configuration --> OxTrust Configuration set scimTestMode property field to true.
For both modes one can verify the protection scheme by querying https://demoexample.gluu.org/identity/restv1/scim/v2/ServiceProviderConfig

Working with Test Mode

Create openID client using Admin credentials in oxtrust UI
Request access token using scim_test_client_id : client_secret.
These can be obtained from gluu ConfigMap and gluu Secret.

➜  Gluu Federation ~ kubectl get cm -o yaml | grep scim_test_client_id       
    scim_test_client_id: 0008-44a4df82-0bcb-4870-a534-ed3721754e06
➜  Gluu Federation ~ kubectl get secret -o yaml | grep scim_test_client_secret
    scim_test_client_secret: 9rR5oJl0YkSF7pNw9FJ2toUT

Make sure to decode the values in secret
- Request

➜  Gluu Federation ~ curl -k -u '0008-44a4df82-0bcb-4870-a534-ed3721754e06:9rR5oJl0YkSF7pNw9FJ2toUT' -d grant_type=client_credentials https://demoexample.gluu.org/oxauth/restv1/token

response

{"access_token":"1999ddf2-9820-42b8-ad97-e096a48e79a0","token_type":"bearer","expires_in":299}

Use the token to hit the SCIM endpoints e.g create Users

curl -k -H 'Authorization: Bearer 1999ddf2-9820-42b8-ad97-e096a48e79a0' -H 'Content-Type: application/scim+json' -d @input.json -o output.json https://demoexample.gluu.org/identity/restv1/scim/v2/Users

Possible points of failure

Test mode
- Using an invalid scim_test_client_secret and invalid scim_test_client_id
- Using a wrong REST API endpoint
- using a different hostname from one configured from time of deployment
UMA mode
- Testing this..

Gluu CN Test scenarios - GluuFederation/cloud-native-edition GitHub Wiki

Cache Refresh

Expected results

steps

Testing twilio sms authentication script

Possible points of failure

Test paths

References

OXAUTH

Expected results

Posible points of failure:

Test paths:

OXTRUST API

Test Mode

Expected Results.

Steps

Possible points of failure

Test Paths

UMA Mode

Expected results.

Steps

Test Paths

References.

SCIM

Expected results

steps

Working with Test Mode

Possible points of failure

Test paths

References

FIDO

Expected results

steps

Possible points of failure

Test paths

References