Genero Identity Provider (GIP)

Genero provides its own Identity Provider for securing applications and RESTful Web services.

Why would I use the Genero Identity Provider?

With the Genero Identity Provider, you can:

  • Secure Web applications and Web services.
  • Manage users and groups.

During the initial configuration of the Genero Identity Provider, you can install the optional deployment service to help deploy and secure applications. See Genero Identity Platform components to learn more about which components make up the Genero Identity Platform, and which services can be added during initial configuration.

How is security managed?

Security is managed by scopes. You can think of a scope as being a permission. There are two categories of scopes:

  • An authorization scope allows access to an application.
  • A scope allows access to a Web service. The term scope comes from the Web service world, where a function uses a scope to secure itself against unauthorized users.

Securing a Web service

The Genero Identity Provider can secure RESTful Web services. To understand how to secure a Web service, you must understand the architecture of a Web service, as it relates to permissioning.

A RESTful Web service is an application that contains one or more resources, and a resource can support multiple operations, as illustrated in Figure 1.
Figure: Architecture of a RESTful Web service


Access is secured by scopes. A scope can be set on a resource or an operation. The Web service sets the scopes in its code, implementing the scope as a string. For example, Figure 1 shows two resources. With the first resource, two of the three operations have a lock displayed. These locks represents scopes set on the operation level. With the second resource, the scope is set on the resource level.

In order to access a resource or operation with a scope assigned, a user must have the required scopes. That scope (string) must be embedded (encrypted) in the access token that the user gets from the Genero Identity Provider, granting them access to the resource or operation. Examine the diagram one more time, you should see that only one operation does not require the user to have a scope assigned.

Securing an application

When you secure an application, you specify which authorization scopes will allow access to the application. In order to access the application, a user must have the required authorization scope.
Figure: Securing an application

Person needs scope to access locked application.
If the application makes calls to a Web service, and the Web service is secured by scopes, the user must also have the scope demanded by that Web service in order to use the operation protected by that scope.
Figure: Securing an application that calls services

Diagram adding services to the application
When defining application access, you can specify that a Web service scope is required or optional.
  • If a scope is required, then a user must have the scope to initially access the application.
  • If a scope is optional, the user can initially access the application, even if the user does not have the optional scope. When a user tries to use a protected resource or operation, and that user does not have the necessary scope, the service sends back an error. It is up to the application to handle the error.

Managing user access

To recap:
  • If the user needs to access an application, then they need to have the authorization scope necessary to access the application.
  • If an application then interacts with a Web service, the user must have the scopes required by that service in order to use the protected resources and operations in that Web service. If a scope has been marked as required, the user must have the scope to initially access the application.

Scopes and authorization scopes are often provided via groups. A group is a collection of authorization scopes and scopes. When a user is made a member of a group, that user inherits all authorization scopes and scopes assigned to that group. In addition to inheriting scopes via group membership, users can be granted scopes directly.

Genero Identity Provider server URLs

The Genero Identity Provider is a Web service that, once set up, is available when the Genero Application Server (GAS) is started. Certain tools used for application deployment via scripts may need to access Genero Identity Provider services on a remote server.

Obtain access to the Genero Identity Provider at the GAS base URL for the services group: 
https://host:port[/gas]/ws/r/services/GeneroIdentityProvider
Obtain Genero Identity Provider metadata at the following URL:
https://host:port[/gas]/ws/r/services/GeneroIdentityProvider/.well-known/openid-configuration