|
10Duke Scale C++ SDK
|
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), an authentication framework built on OAuth 2.0. To use identity-based licensing, you need an OIDC-based identity provider service. If you don't have one configured, contact 10Duke sales for options.
The 10Duke Scale C++ SDK provides two types of OIDC authentication: browser-based authentication and OAuth 2.0 "Device Authorization Grant" authentication. Device authentication is primarily intended for scenarios where the device lacks a browser: the user authenticates out-of-band using a browser on another platform. For browser-based authentication, the client uses the default OS browser to perform the login.
In both cases, the client automatically manages the login session whenever an API method requiring authorization is used:
You do not need to explicitly start login or refresh the session. You can register a callback that gets notified when certain login-related events (for example, login is starting) occur, see Register 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 the 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:
The 10Duke Scale C++ SDK provides browser-based OIDC authentication by default using the operating system default browser and "loopback interface redirection". When a user is authenticated, the client opens the default OS browser and starts the login flow with the OIDC provider. The client simultaneously opens a simple local HTTP server used to detect when the login is complete. After completing the login, the OIDC server issues an HTTP redirect to a preconfigured URL (the redirect URI) in the browser. For details see RFC 8252: 7.3 Loopback Interface Redirection.
The client must be configured with an HTTP message served by the HTTP server after the login is complete. The HTTP message is a full HTTP response with a status line, headers, and a response message entity. This allows, for example, using an HTTP redirect to navigate to an external site after login.
To create a client for browser-based authentication, see the below example:
Note that the redirect URI must start with http://localhost.
If the device running the client lacks a browser, or using the browser is awkward, authentication can be performed using the Device Authorization Grant (or device flow). To start the user login, the device shows an authentication URL and a user code to the user. Using another device (for example, a 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 a user session is set up.
For details of the Device Authorization Grant, see RFC 8628.
When authenticating with device flow, the client must be configured with a callback that is called when the client needs to display the URL for the user. You must implement the display of the relevant information.
Example:
The client automatically manages the user login session. It performs the login (either by opening a browser or by device flow callback) when you use an API that requires a valid user login session, and the user has not yet logged in, or when the login session has expired. The client also refreshes the login session automatically when required. You do not need to trigger the login manually.
You can be notified when the login is starting or complete, or the user session has been refreshed. For example, when the login is complete, you can bring your application to the foreground. This is useful as the browser usually opens on top during the login.
To get the notifications, register the 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 the oidcSessionConfiguration parameter in the OIDC authentication configuration, see below for examples.
A sample listener:
When creating a client for browser-based authentication, register the listener using the oidcSessionConfiguration parameter of tenduke::oidc::osbrowser::BrowserAuthenticationConfig:
When creating a client for device authentication, register the listener using the oidcSessionConfiguration parameter 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.
Check out licenses:
Send a heartbeat for a lease:
NOTE: A heartbeat generates new IDs for the leases.
To release the licenses after a heartbeat:
The licensing client has a memory cache, which holds leases of checked-out licenses and automatically manages the leases after a heartbeat or release request. To list all leases currently in cache:
The client allows you to only operate (heartbeat or release) on leases that are present in the cache. If you want to release all checked-out licenses, you can do:
You can use the tenduke::se::licensing::LicenseConsumers service to query information, for example, on available licenses. To query licensees whose licenses a user can consume, use tenduke::se::licensing::LicenseConsumers.describeLicenseConsumerLicensees():
To list licenses owned by a licensee that a user can consume:
To list licenses that a user has currently checked out:
Get current OIDC ID token for authenticating requests to other 10Duke Scale APIs: