This project is part of the 'IBM Cloud Native Reference Architecture' suite, available at https://cloudnativereference.dev/
This project demonstrates how to authenticate the API user using OpenID Connect in the Storefront reference application. The MicroProfile based Authorization Server is used as an OpenID Connect Provider. This reference application delegates authentication and authorization to this component, which verifies the user credentials.
- MicroProfile based Authorization Server application that handles user authentication and authorization.
- Uses OpenID Connect 1.0 and acts as a provider to validate login credentials.
- Return a mpJwt Bearer token back to caller for identity propagation and authorization.
- When username/password is passed in, the Authorization microservice validates the credentials based on the details configured in the basic registry.
- When a client wishes to acquire an access token to call a protected API, it calls the OpenID Connect Provider (Authorization microservice) token endpoint with the username/password of the user and requests a token with scope
blue
. - Authorization microservice will perform the validation.
- If the username/password are valid, a mpJWT token is returned with an
access token
included in it. - The client uses the
access token
in theAuthorization
header as a bearer token to call other Resource Servers that have the protected API (such as the Orders microservice. - The service implementing the REST API verifies that the
access token
from mpJWT is valid, and then extracts the required claims from the mpJWT to identify the caller. - The mpJWT is encoded with scope
blue
and the the expiry time inexpires_in
; once the token is generated there is no additional interaction between the Resource Server and the Auth server.
Following the OpenID Connect endpoint URLs, the Authorization server exposes both an authorization URI and a token URI.
GET /OP/authorize
POST /OP/token
The Storefront reference application supports the following clients and grant types:
- The Storefront Web Application is using client ID
bluecomputeweb
and client secretbluecomputewebs3cret
supports Password grant type.
The Storefront application has three scopes openid
, admin
, and blue
.
- Appsody
- Installing on MacOS
- Installing on Windows
- Installing on RHEL
- Installing on Ubuntu For more details on installation, check this out.
- Docker Desktop
We created a new openliberty project using appsody as follows.
appsody repo add kabanero https://github.com/kabanero-io/kabanero-stack-hub/releases/download/0.6.5/kabanero-stack-hub-index.yaml
appsody init kabanero/java-openliberty
OpenID Connect Provider - Configure a Liberty server to act as an OpenID Connect Provider by enabling the openidConnectServer-1.0 feature in Liberty. The ssl-1.0 feature is also required for the openidConnectServer-1.0 feature. This OpenID Connect provider is built on the top of OAuth Provider. So, the oauth provider should be configured as well along with the OpenID Connect provider.
Basic User Registry - Liberty Server can be configured with a basic user registry by defining the users and groups information for authentication.
- Clone auth repository:
git clone https://github.com/ibm-garage-ref-storefront/auth-ms-openliberty.git
cd auth-ms-openliberty
- Create a local instance of a Keystore by running the commands below.
keytool -genkeypair -dname "cn=bc.ibm.com, o=User, ou=IBM, c=US" -alias bckey -keyalg RSA -keysize 2048 -keypass password -storetype PKCS12 -keystore ./BCKeyStoreFile.p12 -storepass password -validity 3650
keytool -list -keystore ./BCKeyStoreFile.p12 -storepass password
keytool -export -alias bckey -file client.cer -keystore ./BCKeyStoreFile.p12 -storepass password
keytool -import -v -trustcacerts -alias bckey -file client.cer -keystore ./truststore.p12 -storepass password -noprompt
-
Go to
src/main/liberty/config/resources/security
and copyBCKeyStoreFile.p12
to this location. -
client.cer
andtruststore.p12
will not be used in this particualr microservice. These will be needed by other storefront microservices like orders and customer
- To run the auth application, use the below command.
appsody run
- If it is successfully running, you will see something like below.
[Container] [INFO] Unit tests finished.
[Container] [INFO] Waiting up to 30 seconds to find the application start up or update message...
[Container] [INFO] CWWKM2010I: Searching for (CWWKZ0001I.*|CWWKZ0003I.*auth-ms-openliberty) in /opt/ol/wlp/usr/servers/defaultServer/logs/messages.log. This search will timeout after 30 seconds.
[Container] [INFO] CWWKM2015I: Match number: 1 is [9/11/20 16:23:48:951 UTC] 00000033 com.ibm.ws.app.manager.AppMessageHelper A CWWKZ0001I: Application auth-ms-openliberty started in 3.782 seconds..
[Container] [INFO] Running integration tests...
[Container] [INFO]
[Container] [INFO] -------------------------------------------------------
[Container] [INFO] T E S T S
[Container] [INFO] -------------------------------------------------------
[Container] [INFO] Running it.dev.appsody.auth.EndpointTest
[Container] [INFO] [ERROR ] CWMOT0008E: OpenTracing cannot track JAX-RS requests because an OpentracingTracerFactory class was not provided.
[Container] [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.486 s - in it.dev.appsody.auth.EndpointTest
[Container] [INFO] Running it.dev.appsody.auth.HealthEndpointTest
[Container] [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.315 s - in it.dev.appsody.auth.HealthEndpointTest
[Container] [INFO]
[Container] [INFO] Results:
[Container] [INFO]
[Container] [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[Container] [INFO]
[Container] [INFO] Integration tests finished.
- You can also verify it as follows.
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5e7d299711b5 kabanero/java-openliberty:0.2 "/.appsody/appsody-c…" About a minute ago Up About a minute 0.0.0.0:7777->7777/tcp, 0.0.0.0:9080->9080/tcp, 0.0.0.0:9443->9443/tcp auth-ms-openliberty
Now, you can validate the application as follows.
curl -k -d "grant_type=password&client_id=bluecomputeweb&client_secret=bluecomputewebs3cret&username=foo&password=bar&scope=openid" https://localhost:9443/oidc/endpoint/OP/token
If it is successful, you will see something like below.
$ curl -k -d "grant_type=password&client_id=bluecomputeweb&client_secret=bluecomputewebs3cret&username=foo&password=bar&scope=openid" https://localhost:9443/oidc/endpoint/OP/token
{"access_token":"eyJraWQiOiJmQTJYUzMzM09yajlMZmZFSXZJdCIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJmb28iLCJ0b2tlbl90eXBlIjoiQmVhcmVyIiwic2NvcGUiOlsib3BlbmlkIl0sImp0aSI6IkhLTEgzUlRjM0RodXd6WXAiLCJpc3MiOiJodHRwczovL2xvY2FsaG9zdDo5NDQzL29pZGMvZW5kcG9pbnQvT1AiLCJleHAiOjE1OTk4NDg3MzgsImlhdCI6MTU5OTg0MTUzOCwiZ3JvdXBzIjpbIlVzZXJzIl0sInVwbiI6ImZvbyJ9.Jke__r_QAsCkz80XM8bZradtutQ4DylC6S8o5a2CJ9juXUDnVfvA4FNXrlLm23_ckoRduSJEamjwq5EgeVB7cs3xQ_B0BnnnfYD4Pmqpi-kDXYunMVCtmx6BNzQUo9D6LBnt9YUoz77X2ZoSeWOwj94_YoayBPF6hJYPR-UOKs23a-26sPlH4107tWba1uvIIxvteJ3Xu1oDThryKwQ7VHoNQZ4LRSXUFYeYZSY4IGQ5rYKXqWaCJlF4oaXempKlWnvhTUopVn4qzC9QSKdturyKUpprMUDshdjafeElPmASUbkLfIN-6SnhZdZ5CybLcGEgtXNapKtcez6vdJvyww","token_type":"Bearer","expires_in":7200,"scope":"openid","refresh_token":"88ioTtUzZpk0XfZx6U1vmYvksXNpHAwvlqJfOxDWCHqqWO7lFA"}
Originally, in the storefront application, this microservice will talk to customer microservice and validate the credentials. To make it easy for local validation, we enabled a test user which can be used to verify the functionality of this application.
To exit the application, just press Ctrl+C
.
It shows you something like below.
[Container] [INFO] [AUDIT ] CWWKE0036I: The server defaultServer stopped after 4 minutes, 58.597 seconds.
[Container] [WARNING] CWWKM2133W: The command to stop server defaultServer failed. The server is probably already stopped.
[Container] [INFO] ------------------------------------------------------------------------
[Container] [INFO] BUILD SUCCESS
[Container] [INFO] ------------------------------------------------------------------------
[Container] [INFO] Total time: 05:12 min
[Container] [INFO] Finished at: 2020-09-11T16:28:36Z
[Container] [INFO] ------------------------------------------------------------------------
[Container] + set +x
[Container] The file watcher is not running because no APPSODY_RUN/TEST/DEBUG_ON_CHANGE action was specified or it has been disabled using the --no-watcher flag.
Closing down development environment.
You have successfully deployed and tested the Auth Microservice in local Docker Containers using Appsody.
To see the Auth application working in a more complex microservices use case, checkout our Microservice Reference Architecture Application here.