RBAC/Single Sign-On
Traditional user-based access control management can be expensive, as users in an organization change relatively frequently.
However, in a well-defined modern business process, the permission to perform a specific task in a controlled procedure is
granted to a role rather than to an individual user. A role is defined based on the task required by a specific job function as well as on the authority and responsibility implied with this function. An individual person ("user") is then assigned
one or more role(s), by virtue of which the person is granted permission to e.g. execute an operation command or to access
data on a system.
Rolf Stalder, manager of PCS Systems Hardware & Software Engineering, answers 10 key questions on the topic:
The new PMCS Module
Current PMCS Releases feature a RBAC/SSO Module. This module extends PMCS's access control capabilities. Furthermore Single Sign-On (SSO) enhances interface usability. Rolf Stalder, manager of PCS Systems Hardware & Software Engineering, answers 10 key questions on the topic:
Rolf Stalder
Former PMCS Releases featured a level-authorization model. What were the issues with this access control model?
In the existing level authorization there is no strict separation between the authentication and the authorization checks. The levels are partly hard-coded in the applications or they can be configured for one GUI instance only. Furthermore many applications are not subject to authorization checks. Of course we could have redesigned the existing level authorization. For several reasons, however, we preferred to develop an authorization wrapper instead. To prevent the execution of PMCS programs, all PMCS programs would have to be integrated into the present level authorization. In order to offer a more flexible rights management, we'd additionally have to implement an administration tool. That would be far too expensive. For many PMCS programs the UNIX-authorization can be identified as the only meaningful and useful authorization. To keep the authorization required for the technical operation in SSO Mode the implementation of an authorization wrapper is mandatory, as PMCS does not separate between client and server programs. The authorization wrapper of the Solaris OS is based on the RBAC model, and its API allows it to be integrated into applications at relatively low expense.
Application-specific authorization could in the long term be flexibly administrated by means of the RBAC mechanism and thus replace the currently used level-checks.
The PMCS level authorization is backward-compatible. The RBAC mode presently allows for an additional way to assign privileges. It is not (i.e. not yet) a substitute for the level authorization in PMCS.
What are the key advantages of the RBAC model as compared to the traditional UNIX user/group model?
A role is defined by business logic, it represents a job function. Roles therefore change rarely, unlike users. New employees join the staff, replacing others that leave the company, staff members are promoted, new applications are introduced and replace existing applications, all these are events that may occur quite frequently in a company. Roles are an optimal way to link business logic to application logic. A job function can easily be understood by all people involved in a business process, application-specific authorization, however, often does not go without saying. Even in systems that are technically lacking a role-based model, the role concept can help to derive technical authorization from business logic.
What are the components of the new PMCS module, what technologies do you use?
For Single Sign-On we use MIT's Kerberos Server and the associated libraries. The GUI/CLI part is based on GTK/GLIB and Glade/Libglade.
Our own development consists of a special library for the SSO functionality, and of course several PMCS programs had to be modified. Furthermore we developed a graphical and a commandline login/logout program.
The RBAC wrapper application for PMCS programs is based on the Solaris RBAC library.
Will the customers have to face additional costs for implementing RBAC/SSO in PMCS applications?
Yes, but only if there is additional need for support by PCS, e.g. for the definition and elaboration of roles. On the software side there are no additional costs.
How do you manage privileges in complex systems with several process computers?
Solaris RBAC can be operated with a directory service (NIS or LDAP) as a back-end. This allows for centralized configuration and administration of the authorization data.
21 CFR 11 (11.300) requires that an electronic signature be unique, i.e. that it can be unambiguously assigned to a person and his/her function. Does the PMCS Single Sign-On module comply with this requirement?
Yes, the executing user is still recorded at the "level check points".
Are there any process-related risks that could arise from implementing RBAC/SSO?
In SSO operating mode (exactly as in 'traditional' mode) it is assumed that the user does not wantonly bypass authentication or violate security policy, fail to log out, divulge authentication data, for instance. In SSO there is of course the risk of a person forgetting to log out. On the other hand it must be taken account of the fact that in the traditional operating mode the frequent password inputs may increase the probability for someone spying on a user while he inputs his credentials.
What does Single Sign-on mean in PMCS Context?
A session-based operating mode of PMCS with personalized accounts. For each user a program instance is started, program instances are not shared. Programs are started with the personal UNIX ID of the user. The user logs in to the PMCS application at the first level-check, or explicitly by using the Single Sign-On client application. Thereafter he keeps the according level-authorization for the configured valid time of the ticket. The user can, however, at any time delete his credentials (log out) and will be prompted for a password the next time he has to pass a level-check. The user's system password is used as a PMCS password, too. As the username is known from the UNIX environment, it can't be input or modified in the password dialogs.
So, if a user is logged in to the UNIX system as "supervisor1" there is no way for him to run PMCS as e.g. "operator1" or vice versa?
That's correct, if RBAC and SSO are used, this behaviour is prevented by intention. When using RBAC without SSO, however, it is possible, but only by means of the PMCS password database.
For which PMCS Versions are the RBAC/SSO modules available? Is it possible to upgrade existing PMCS systems?
The RBAC Module is available for PMCS R7 and R8 as well as for the current PMCS Version. The SSO Module is supported by the current PMCS Version as of Iteration 1.0.0.
Of the SUN Operation Systems, Solaris 10 (Intel and SPARC) Solaris 8 SPARC are supported for RBAC. For SSO, Solaris 10 (Intel and SPARC) and Solaris 8 SPARC. For the latter, SSO client is not supported.
Upgrading existing PMCS systems is possible according to these restrictions. For Solaris 8 Systems, however, we recommend an upgrade to Solaris 10.
Further Information on RBAC/SSO
In the existing level authorization there is no strict separation between the authentication and the authorization checks. The levels are partly hard-coded in the applications or they can be configured for one GUI instance only. Furthermore many applications are not subject to authorization checks. Of course we could have redesigned the existing level authorization. For several reasons, however, we preferred to develop an authorization wrapper instead. To prevent the execution of PMCS programs, all PMCS programs would have to be integrated into the present level authorization. In order to offer a more flexible rights management, we'd additionally have to implement an administration tool. That would be far too expensive. For many PMCS programs the UNIX-authorization can be identified as the only meaningful and useful authorization. To keep the authorization required for the technical operation in SSO Mode the implementation of an authorization wrapper is mandatory, as PMCS does not separate between client and server programs. The authorization wrapper of the Solaris OS is based on the RBAC model, and its API allows it to be integrated into applications at relatively low expense.
Application-specific authorization could in the long term be flexibly administrated by means of the RBAC mechanism and thus replace the currently used level-checks.
The PMCS level authorization is backward-compatible. The RBAC mode presently allows for an additional way to assign privileges. It is not (i.e. not yet) a substitute for the level authorization in PMCS.
What are the key advantages of the RBAC model as compared to the traditional UNIX user/group model?
A role is defined by business logic, it represents a job function. Roles therefore change rarely, unlike users. New employees join the staff, replacing others that leave the company, staff members are promoted, new applications are introduced and replace existing applications, all these are events that may occur quite frequently in a company. Roles are an optimal way to link business logic to application logic. A job function can easily be understood by all people involved in a business process, application-specific authorization, however, often does not go without saying. Even in systems that are technically lacking a role-based model, the role concept can help to derive technical authorization from business logic.
What are the components of the new PMCS module, what technologies do you use?
For Single Sign-On we use MIT's Kerberos Server and the associated libraries. The GUI/CLI part is based on GTK/GLIB and Glade/Libglade.
Our own development consists of a special library for the SSO functionality, and of course several PMCS programs had to be modified. Furthermore we developed a graphical and a commandline login/logout program.
The RBAC wrapper application for PMCS programs is based on the Solaris RBAC library.
Will the customers have to face additional costs for implementing RBAC/SSO in PMCS applications?
Yes, but only if there is additional need for support by PCS, e.g. for the definition and elaboration of roles. On the software side there are no additional costs.
How do you manage privileges in complex systems with several process computers?
Solaris RBAC can be operated with a directory service (NIS or LDAP) as a back-end. This allows for centralized configuration and administration of the authorization data.
21 CFR 11 (11.300) requires that an electronic signature be unique, i.e. that it can be unambiguously assigned to a person and his/her function. Does the PMCS Single Sign-On module comply with this requirement?
Yes, the executing user is still recorded at the "level check points".
Are there any process-related risks that could arise from implementing RBAC/SSO?
In SSO operating mode (exactly as in 'traditional' mode) it is assumed that the user does not wantonly bypass authentication or violate security policy, fail to log out, divulge authentication data, for instance. In SSO there is of course the risk of a person forgetting to log out. On the other hand it must be taken account of the fact that in the traditional operating mode the frequent password inputs may increase the probability for someone spying on a user while he inputs his credentials.
What does Single Sign-on mean in PMCS Context?
A session-based operating mode of PMCS with personalized accounts. For each user a program instance is started, program instances are not shared. Programs are started with the personal UNIX ID of the user. The user logs in to the PMCS application at the first level-check, or explicitly by using the Single Sign-On client application. Thereafter he keeps the according level-authorization for the configured valid time of the ticket. The user can, however, at any time delete his credentials (log out) and will be prompted for a password the next time he has to pass a level-check. The user's system password is used as a PMCS password, too. As the username is known from the UNIX environment, it can't be input or modified in the password dialogs.
So, if a user is logged in to the UNIX system as "supervisor1" there is no way for him to run PMCS as e.g. "operator1" or vice versa?
That's correct, if RBAC and SSO are used, this behaviour is prevented by intention. When using RBAC without SSO, however, it is possible, but only by means of the PMCS password database.
For which PMCS Versions are the RBAC/SSO modules available? Is it possible to upgrade existing PMCS systems?
The RBAC Module is available for PMCS R7 and R8 as well as for the current PMCS Version. The SSO Module is supported by the current PMCS Version as of Iteration 1.0.0.
Of the SUN Operation Systems, Solaris 10 (Intel and SPARC) Solaris 8 SPARC are supported for RBAC. For SSO, Solaris 10 (Intel and SPARC) and Solaris 8 SPARC. For the latter, SSO client is not supported.
Upgrading existing PMCS systems is possible according to these restrictions. For Solaris 8 Systems, however, we recommend an upgrade to Solaris 10.
Further Information on RBAC/SSO
Our Systems Hardware & Software Department will be glad to answer your questions on PMCS and RBAC/SSO.
