Authorization

This information explains the process of authorization, some different authorization methods, and the role it plays in a single signon solution.

Authorization is a process in which a user is granted access to a network or system resource. Most enterprises use a two-stage process to allow users to access network assets. The first stage of this process is authentication. Authentication is a process in which a user identifies themselves to the enterprise. Typically this requires the user to provide an identifier and a password to the security component of the enterprise. The security component verifies the information that it receives. After a successful authentication, the user is issued a process they can use, a credential, or a ticket to use to demonstrate that they have already authenticated to the enterprise. An example of a user authentication is the ID and password challenge on an iSeries™ Navigator connection. After successful authentication, the user is assigned a job that runs under their user ID. The second stage is authorization. It is important to know the distinction between authentication and authorization.

Authorization is the process of determining if an entity or person has the authority to access an asset within an enterprise. Authorization checks are done after a user has authenticated to the enterprise, because authorization requires that the enterprise knows who is trying to gain access. Authorization checking is mandatory and occurs as part of the system. Users are typically unaware that authorization checks occur unless their access is denied. An example of authorization occurs when a user uses the command CRTSRCPF QGPL/MYFILE. The system performs authorization checks on the command CRTSRCPF and the library QGPL. If the user does not have the authority to access the command and the library, the user's request fails.

An enterprise that has implemented the i5/OS™ single signon solution uses Enterprise Identity Mapping (EIM) to manage user access to enterprise assets. While EIM does not perform authorization checks, the identity mapping establishes the local identities for users that have successfully authenticated into the enterprise. The source (or user) receives access and privileges on the target system through the local ID. For example, assume you have the following simple enterprise environment:

Employee Name (EIM Identity)	Source Users (EIM Source)	Target users for System A (EIM Target)	Employee Responsibility	System A User Comments
Susan Doe	SusanD	SecOfficer	IT Security Officer	All special authority. Has access to all files and information.
Fred Ray	FredR	PrimeAcnt	Lead Accountant	No special authority. Has access to all payroll information.
Nancy Me	NancyM	PrimePGM	IT Application Team Leader	No special authority. Has access to all company application source files.
Brian Fa	BrianF	GenAcnt1	Accountant	No special authority. Has access to some payroll information.
Tracy So	TracyS	ITPgm2	IT Programmer	No special authority. Has access to some company application source files.
Daryl La	DarylL	ITPgm3	IT Programmer	No special authority. Has access to some company application source files.
Sherry Te	SherryT	PrimeMKT	Marketing Representative	No special authority. Has access to all marketing data.

It is important that all of the associations between users and resources are set up correctly. If the associations are incorrect, users will have access to data outside the scope of their responsibilities, which is a security concern for most enterprises. System administrators need to be very careful when creating the EIM mappings and ensure that they map users to the correct local registry IDs. For example if you mapped the IT Programmer, Daryl La, to the SecOfficer ID instead of Susan Doe, you could compromise the security of the system. This reinforces the fact that security administrators must still take care in securing the target systems within the enterprise.