General handling of roles

For many purposes, the roles of nevisIDM are treated in the same way as the roles of any other application:

• Roles belong to an application ("nevisIDM"). To avoid name clashes, the application name is taken as the prefix of the full role name.
• The nevisIDM back end of nevisAuth fetches all roles from the user's profile and adds them to the secToken and to the return value of the authentication call. The output also contains the values of the properties of the roles for later delegation.
• A SecurityRoleFilter in nevisProxy can check for the presence of a certain set of roles.
• A DelegationFilter in nevisProxy can delegate the secToken roles and properties to the application.
• The application can verify the secToken using Ninja. Ninja also makes the roles available for checking in the web application.

The points above explain why a user has to log in again in order for recently added roles to be active in his session. As long as a user keeps his old session, he has a secToken without the new roles. With a new login, he will get a secToken with the new roles.