Built-in IDP
All tenants have a built-in, optionally enabled OpenID Connect identity provider component, which can be used to delegate the logged in user's identity from the encryption platform to the integrated application(s) in a secure and standardized way.
Concept
The idea behind the integrated IDP component is to provide a standard way for the integrated web or mobile app to consume the identity of the users. Because the user login takes place through the ZeroKit web or mobile SDK, identity propagation needed to ensure the backend service of the web (or mobile) application about the user's identity. The ZeroKit sdk itself can determine and provide the logged in user's identity, but that information can only be trusted at the client-side part of the integrated app. The backend of the app may need a more trustworthy source than what the client side can provide. This source is the optionally enabled IDP component.
Protocol
The OpenID/Connect protocol was chosen because this standard is one of the most modern and secure protocols, which offers easy integration with web applications. The integrated IDP component is an officially OpenID/Connect certified component, which offers full support of the protocol.
The OIDC API itself is accessible at the {serviceUrl}/idp address where {ServiceUrl} stands for the service URL displayed on the management portal for the tenant.(Usually its https://{TenantId}.api.tresorit.io/idp)
Configuration
Before usage the IDP component must be activated and configured. Clients can be configure and en/disabled on the administrative portal, on the configuration page of your tenant in the "Identity provider section".
Here you can enable/disable the whole IDP module, and also add, configure or remove clients. On the basic configuration page you can edit the Name of your client, edit redirection URL list and copy the client ID and secret.
Client name: A readable name which helps to identify your client properly. This name used only by the portal and in logs, but not by any code. You can change it any time.
Client ID: this is an auto-generated id of your client. This ID is immutable, and used by the OpenID COnnect client libraries to identify your client.
Client secret: this is an auto-generated secret value used by the OpenID Connect client libraries with some OpenID flows.
Redirect URLs: a list of web URLs where your user is allowed to be redirected by the consumer of the IDP (your applications) after a successful login.
If you enable the "Advanced options", you can also set the used OpenID Connect flow and the list of allowed CORS origins.
Flow: Selected OpenID flow for the client. The flows are well-defined sequences in the OpenID Connect standard. You can choose Hybrid (default), Authorization code _or _Implicit flow.
Requires proof key: In the case of Hybrind or Authorization code flows you can turn on this option. Proof key usage is an extension of the OpenID connect standard which improves security in some cases, especially when the consumer is a mobile app. You client have to support this option.
Cors origins: Some IDP APIs can be called from JavaScript code as well (especially when Implicit flow is used). As your app (consumer) and the platforms server (provider) is hosted on different domains, you have to allow these calls by configuring your origin domains.
Note: The allowed scopes are "openid" and "profile", and the only returned claim will be the user identifier as the value of the sub (subject identifier) claim.
Note: Please note, that IDP configuration changes like any other changes on the admin portal made against a tenant, may take up to 5 minutes for a change to be effective.
Note: The integrated IDP will not show consent screens as this is not a public IDP service and your application(s) is will be the only client(s) of it.
Debugging
If the client configuration either on client or server side contains an error, it can be very hard to find out what causes the problem. To make this easier, we implemented an extensive logging for the IDP. This logging can be turned on by tresorit if you ask for it on the red carpet channel, and then we can provide logs. This logging should only be activated for as long as it's needed, because the logging is resource wasting and can cause security issues if left on for long periods of time, because it may also log sensitive token data. It's a very useful tool for debugging, but please be considerate with its usage.
Example
Here you can see the shortest possible client config of the IDP component of the ZeroKit platform and the client-side pair of the same config implemented in a C# client using standard OWIN components.
Client config (at ZeroKit Admin portal):
Client config (web app side):
| Example |
public class Startup{ public void Configuration(IAppBuilder app) { app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = "cookies" }); app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions() { AuthenticationType = "oidc", SignInAsAuthenticationType = "cookies", Authority = "https://[serviceUrl.api.tresorit.io/tenant-mytenant/idp](http://host-myhost.api.tresorit.io/tenant-mytenant/idp)", // Use the service URL of your tenant ClientId = "ua8zpwlxq5_4777cy43iL", // Use your client id from the portal ClientSecret = "ytjwe8skrjg2zhvs", // Use the secret of your IDP client from the portal RedirectUri = "[http://localhost:4455/](http://localhost:4455/)", // The desired redirect location after login ResponseType = "id_token token", Scope = "openid profile" }); }
}
|
Note: This is a full configuration of an OWIN web app, the absolute relevant config lines are lines 8-14.