Genero Identity Provider scenario

This scenario provides an overview of the process for securing applications and Web services resources with the Genero Identity Provider (GIP).

ABC Farmers is implementing a system to help them sell apples and oranges. They have written a Web service to manage their sales of fruit. Access to the Web service is provided by a browser-based application, to be made available to all ABC Farmers customers, workers, and managers. This scenario takes you through the process of securing both the Web service and the application, while setting up access for users based on their roles (customer, worker, or manager).

Create the groups

It is more efficient to secure an application for a group of users than on a user-by-user basis. Towards this end, the administrator starts by creating user groups based on the different roles, as shown in Figure 1.

Figure: Groups created for ABC Farmers


For each group, the administrator selects the scope of Role.User (for the Authorization API), as each member of these groups is a "standard user of Genero Identity Platform". In addition, the default scope openid (for the OpenID API) is kept, as it is required for the Genero Identity Provider and single sign-on. Figure 2 shows the initial scopes selected for the ABC Farmers Customer group; the scopes for the Worker and Manager groups would be identical at this stage.

Figure: Scopes of the ABC Farmers Customer group

Screen shot of ConsoleApp.

Secure the Web service

With the groups created, the administrator continues to secure the Web service.

ABC Farmers have written a Web service to manage their resources:
  • Customers can find out what fruit is available and purchase the fruit.
  • Farm workers can update the inventory when new produce arrives.
  • Farm managers can set prices.
In the Genero Web service application, scopes were set to secure the resources and operations, as seen in Figure 3.
Figure: ABC Farmers Web Service resources and operations (with scopes defined)

Graphic showing two resources, apples and oranges. Each resource has four operations: viewInventory, purchase, updateQty, setPrice. Scopes set include access to the resource (abcFarmers on resource itself), update resource operation (update.apples, update.oranges), and update price operation (set.price).
The administrator must register these scopes with the Genero Identity Provider. From the ConsoleApp, The administrator registers the scopes for the Web service, as seen in Figure 4.
Figure: Registered scopes for the ABC Farmers Web service.

Screen shot from ConsoleApp

Secure the application

A secured browser-based application provides the interface to the Web services resources and operations. Customers use the application to search for and purchase the fruits, farm workers use it to update the quantities on hand, and farm managers use it to update prices. To secure this application, the administrator sets the application's authorization scope to Role.User. A user must have the Role.User scope to access the application.
Figure: Authorization scopes for the ABC Farmers Portal application

Screen shot of authorization scope page in Console App.
The application is an interface to the ABC Farmers Web service. When considering which scopes a user needs to use the application, the administrator must also account for the scopes set in the Web service, as shown in Figure 6.
Figure: ABC Farmers scopes


The administrator must determine which scopes are required and which are optional. For the ABC Farmers Web service, if a user does not have the abcFarmers scope, they will not be able to access any of the resources or operations. Customers, however, will not need the update.apples, update.oranges, or setprice scopes. Based on this analysis, the administrator sets the required and optional scopes for the ABC Farmers Portal application, as shown in Figure 7 and Figure 8.

Figure: Required scopes the ABC Farmers Portal application

Screen shot of ConsoleApp.

Users without the abcFarmers scope will not be allowed to start the application, as it is a minimum scope requirement. The openid scope is required for authentication purposes.

Figure: Optional scopes for the ABC Farmers Portal application


Users without the optional scopes will still be allowed to start the application, however they will not be able to access the operations protected by those scopes.

Set scopes for groups

The administrator has defined the user groups, registered the scopes for the Web service, and secured the browser-based ABC Farmers Portal application. Next, the administrator selects the scopes for each group.

A customer needs the abcFarmers scope to access the resources. This scope is added to the ABC Farmers Customer group, as shown in Figure 9.
Figure: Scopes added for the ABC Farmers Customer group


A worker also needs the abcFarmers scope to access the resources. In addition, the worker needs the update.apples and update.oranges scopes to update the inventory of oranges and apples as new shipments arrive. These scopes are added to the ABC Farmers Worker group, as shown in Figure 10.
Figure: Scopes added for the ABC Farmers Worker group

Screen shot of ConsoleApp
The manager group also needs the abcFarmers scope to access the resources. In addition, the manager needs the setprice scope to update the prices of apples and oranges. These scopes are added to the ABC Farmers Manager group, as shown in Figure 11.
Figure: Scopes added for the ABC Farmers Manager group


The scopes for each of the three groups are set.

Assign groups to users

With the scopes for the groups set, the administrator must now select which group or groups each individual user belongs to. A user can belong to multiple groups; for example, a person can be both a customer (viewing and purchasing fruit) and a manager (setting fruit prices). The administrator selects the groups for each user, as shown in Figure 12.
Figure: Example: List of groups user "fred" belongs to

Screen shot of ConsoleApp, user group assignment page

The user inherits the scopes assigned to the groups in which they belong. In the ConsoleApp interface, scopes inherited by group membership display as selected but with a faded gray font, as shown in Figure 13.

Figure: Example: List of scopes for user "fred"

Screen shot of ConsoleApp, user group assignment page

If groups are used well, there should never be a need to select scopes directly for a user. When a new user is registered with the Genero Identity Provider, the administrator only needs to select which groups are a match for that user, and user setup is complete.

Secure a service (script) application

The ABC Farmers managers do not always want to log in to the application to update pricing; they have already entered prices into another system. An application – a back-end service with no user interface – has been created to update the pricing of fruit based on data pulled from other systems. The script is scheduled to run daily. The script will need access to the secured Web service to complete the pricing updates.

The administrator creates a service to service application entry for the back-end service, and selects the scopes needed by the back-end service to update the prices. The scopes needed include the abcFarmers scope required to access the resources and the setprice scope required to access the operation to update the prices. These scopes are added to the service, as shown in Figure 14.
Figure: Service to Service app

Screen shot of ConsoleApp

Now, the script will be able to use the GetToken tool to retrieve an access token to be used to update the prices, as it has the required scopes.

Scenario summary

This has been an example of using the Genero Identity Provider to complete its two main goals:
  • Securing applications and RESTful Web services.
  • Managing users and groups.
For more information on writing a RESTful Web service, refer to the Genero Business Development Language User Guide.