|
10Duke Scale C++ Client
|
10Duke Scale supports identity-based licensing for users: Users authenticate themselves and every operation tracks the users identity. For authentication, 10Duke Scale uses Open ID Connect (OIDC), which is an authentication framework built on OAuth 2. To use identity-based licensing, you need an OIDC-based identity provider service. If you don't have one configured, contact our sales for options.
10Duke Scale C++ client provides two types of OIDC authentication: Browser-based authentication and OAuth 2 "Device Authorization Grant" authentication. Device authentication is mostly intended for scenarios, where the device does not have browser: The user authenticates out-of-band using browser on another platform. For browser-based authentication, the client uses default OS-browser to perform the login.
In both cases, the client manages the login session automatically whenever API-method needing authorization is used:
Application developer does not need to explicitly start login or refresh the session. You can register a callback, which gets notified, when certain login-related events (e.g. login is starting) happen, see Registering session event listener for details.
The service to use with identity-based licensing is tenduke::se::TendukeClientWithOIDCSession. See also the client concepts.
To create the client for browser-based authentication:
tenduke::se::createTendukeClientForBrowserUsingAutodiscovery(const std::string &,const tenduke::se::BackendConfiguration &,const tenduke::se::ClientProperties &,const std::string &,const tenduke::oidc::osbrowser::BrowserAuthenticationConfig &,const std::string &,const ::tenduke::ServiceConfiguration &)tenduke::se::createTendukeClientForBrowser(const std::string &,const tenduke::se::BackendConfiguration &,const tenduke::se::ClientProperties &,const tenduke::oauth::OAuthBackendConfiguration &,const tenduke::oidc::OIDCConfiguration &,const tenduke::oidc::osbrowser::BrowserAuthenticationConfig &,const std::string &,const ::tenduke::ServiceConfiguration &)To create the client for device authentication, use factory functions:
tenduke::se::createTendukeClientForDeviceClientUsingAutodiscovery(const std::string &,const tenduke::se::BackendConfiguration &,const tenduke::se::ClientProperties &,const std::string &,const tenduke::oidc::device::DeviceAuthenticationConfig &,const std::string &,const ::tenduke::ServiceConfiguration &)tenduke::se::createTendukeClientForDevice(const std::string &,const tenduke::se::BackendConfiguration &,const tenduke::se::ClientProperties &,const tenduke::oauth::OAuthBackendConfiguration &,const tenduke::oidc::OIDCConfiguration &,const tenduke::oidc::device::DeviceAuthenticationConfig &,const std::string &,const ::tenduke::ServiceConfiguration &)Note the following client limitations:
10Duke Scale C++ client provides default browser-based OIDC authentication using operating system default browser and "loopback interface redirection": When user needs to be authenticated, the client opens default OS-browser and starts the login flow with the OIDC-provider. The client simultaneously opens a simple local HTTP-server, which is used to detect when the login is complete: When the login is complete, the OIDC server will issue HTTP-redirect to a pre-configured URL (the redirect-uri) in the browser. For details see RFC 8252: 7.3 Loopback Interface Redirection.
The client has to be configured with HTTP-message, which is served by the HTTP-server after the login is complete. This HTTP message is full HTTP-response, with status line, headers and response message entity. This allows e.g. using HTTP-redirect to navigate the browser to a external site after login.
For example, to create client for browser-based authentication:
Note that the redirect uri must start with http://localhost.
If the device, where the client is running, does not have a browser, or using the browser is awkward, the authentication can be done using "Device Authorization Grant", aka. device flow. To start the user login, the device shows an authentication URL and so called "user code" to the user. Using another device (e.g. computer or tablet), the user starts authentication by navigating to the given URL and entering the user code. Once the authentication is complete, the client is notified and user session is set up.
For details of the Device Authorization Grant, see RFC 8628.
When authenticating with device flow, the client has to be configured with a callback, which is called when the client needs to display the URL where user must navigate. The application developer has to implement the display of the information.
Example:
The client manages the user login session automatically by performing login (either by opening browser or by device flow callback) when you use API which needs valid user login session and the user has not yet logged in or when th login session has expired. The client also refreshes the login session automatically, when required. The application developer does not need to trigger login manually.
You might want to be notified, when login is starting, login is complete or the user session has been refreshed. For example, when login is complete, you might want to bring your application on top of all other windows: in browser login, the browser usually opens on top and you want to bring the user back to your application.
To get the notifications, register instance of tenduke::oidc::OIDCSessionEventListener when creating the client. You can also inherit from tenduke::oidc::DefaultOIDCSessionEventListener, which has empty default implementations for all the callback methods. To configure the listener, use parameter oidcSessionConfiguration in the OIDC authentication configuration, see below for examples.
A sample listener:
When creating a client for browser-authentication, register the listener using parameter oidcSessionConfiguration of tenduke::oidc::osbrowser::BrowserAuthenticationConfig:
When creating a client for device-authentication, register the listener using parameter oidcSessionConfiguration of tenduke::oidc::device::DeviceAuthenticationConfig:
For fully working sample, see identity_based_client_example.cpp under examples.
Here are some examples on how to work with the client. For further details and complete API documentation, see tenduke::se::TendukeClientWithOIDCSession.
Checkout licenses:
Heartbeart the lease:
NOTE: Heartbeat generates new ids for the leases.
To release the licenses after heartbeat:
The licensing client has a memory cache, which holds leases of checked out licenses and manages the leases automatically after heartbeat or release request. To list all leases currently in cache:
The client allows you to only operate (heartbeat or release) on leases, which are present in the cache. If you want to release all checked out licenses, you can do:
Service tenduke::se::licensing::LicenseConsumers can be used to query information e.g. about available licenses. For example, to query Licensees, whose licenses user can consume, use tenduke::se::licensing::LicenseConsumers.describeLicenseConsumerLicensees():
To list licenses owned by Licensee, which the user can consume:
To list licenses the user has currently checked out:
Get current OIDC ID-token for authenticating requests to other 10Duke Scale APIs: