IntelliGrid Architecture

 

 

Home

Parent Menu

Same Level Menu

Child Menu

 

Search IntelliGrid Site

Questions/Comments

Questions

 

Responses

 

 

User and Group Account Management

This service allows the ability to define, assign, organize, control and maintain mapping for user and group identifiers within the security domain. There is no authoritative technology that is applicable to providing this service and therefore must be rigorously addressed via policy.

However, there are several relevant articles that may prove of assistance.


Table 34: Relevant Articles concerning User and Group Account Management

Oblix

Best Practices in Extranet Portals and Identity Management

Oblix

Mastering Supply Chain Partnerships: Achieving Core Business Objectives through Effective Identity Management

Available from: http://www.oblix.com/resources/whitepapers/index.html

Oblix

Lowering eBusiness Administrative Costs with Effective Group Management

Available from: http://www.oblix.com/resources/whitepapers/index.html

Oblix

An Overview of Federated Identity Architecture

Available from: http://www.oblix.com/resources/whitepapers/index.html

Oblix

Creating a Secure and Unified eBusiness Infrastructure

Available from: http://www.oblix.com/resources/whitepapers/index.html

Oblix

An Overview of Federated Identity Architecture

Available from: http://www.oblix.com/resources/whitepapers/index.html

Oblix

Creating a Secure and Unified eBusiness Infrastructure

Available from: http://www.oblix.com/resources/whitepapers/index.html

Computerworld

Five rules for top-notch user management and provisioning

Available from:
http://www.computerworld.com/securitytopics/security
/story/0,10801,90407,00.html?f=x10

If thoroughly reviewed, the articles clearly indicate that the basic premise of User and Group Management has its foundations in Identity management (e.g. Identity Establishment and Mapping services). Thus, the technological recommendations from those security services needs to be part of the User and Group Management service. Additionally, the following are key recommendations from the literature:

·       Deprecation or changing of all default accounts is needed.

This would mean that for Operating Systems, that the default user accounts should be removed or a least have the credentials changed (e.g. passwords). This should include ALL user accounts, including remote diagnostic accounts.

·       Accounts that are not frequently used should be de-activated.

One of the most prevalent issues is determining the usage of a particular user account. The Security Domain’s policy should specify a period of inactivity that causes user accounts to become inactive (e.g. no longer valid but available to be renewed/re-activated).

·       Group Accounts should be granular enough to provide appropriate access privilege restriction.

At a general level, the following privileges need to be addressed:

Remote Login: Does the User belong to a group that has the privilege to make use of the computational resource remotely.

Execute: Does the User belong to a group that has the privilege to execute a particular program/application.

Access: Does the User belong to a group that has the privilege to access the information contained in a computational resource (e.g. file, database, etc…). There is a need for further granularity based upon the particular instance of file/resource.

Modification: Does the User belong to a group that has the privilege to modify the information contained in a computational resource. Similar granularity to Access is typically needed.

View: Does the User belong to a group that is allowed to view the existence of a particular resource (e.g. the ability to have a directory with particular files appearing in the directory response).

Within the IntelliGrid Architecture, there are two additional privileges that need to be considered. These are privileges that typically relate to interactions with field devices and not business level computational resources, although they may be needed in some cases (e.g. User Management): Configuration and Control Privileges.

Configuration: Does the user belong to a group that has the privilege to change the configuration of a computational resource. There may be further granularity required based upon the types of configuration supported by the computational resource (e.g. users, protective schemes, control settings, initial values, setting groups, etc.).

Control: Does the user belong to a group that has the privilege to change /control real-time process aspects of a computational resource. Further granularity may need to be provided based upon the class of controllable resources available on a computational resource.

·       Within a Security Domain, there needs to be centralized management and storage of the user/account information, typically in a directory like environment.

·       Single Sign-On is a typical objective of intra-domain management.


This service can be subdivided into a policy part and an actual security service: Setting and Verifying User Accounts.

Setting and Verifying User Accounts Service

This service is for assigning and validating authority given to a user or a group of users in accessing/utilizing specific enterprise resources.

There is no authoritative technology to evaluate for this service. However, from an abstract security service level such a service needs to exist. The service needs to provide the functionality of:

·       Lifecycle management of user and group account. This includes the ability to create, renew, deprecate, modify, and delete users and groups.

·       Credential Management is required so that passwords, certificates, etc. can be replaced/renewed/deprecated as required.

IntelliGrid Architecture
Copyright EPRI 2004