Setting up authorization for runtime users of your application

In Production environments, data access is controlled by USoft Authorizer in the same way as in Development.

However, the procedure for setting up Production authorization is very different. This is because in most applications, almost all production-time authorization is determined at development time and then deployed as part of an application release. Between application releases, authorization in Production remains typically unchanged, except for:

•The list of users that have access to the application. It must typically be possible to add new users, and to drop existing users, between application releases.

•The role or roles that given users play in the application (the group or groups that they belong to). For example, it is often important to be able to promote a given user from read-only access to more extensive access rights.

In Production environments, there are end users who perform specific tasks within the application, and there are administrator users such as helpdesk officers who have more global privileges:

•The authorization of end users is shaped as a runtime facility by developers and then deployed into Production. The functionality of introducing new users in a specific role is usually part of the application itself. When deploying subsequent releases, it is important that deployment procedures keep existing end user information intact.

•The authorization of administrator users is set up in much the same way as for users in Development environments (see Setting up authorization for developers). For example, a new helpdesk officer may be given access to the runtime application by being given a USoft Binder file with a password. When administrator users leave the company, USoft Authorizer is typically the runtime interface for changing their password or dropping their name.