Introducing role-based security with OpsMgr

Role-based security has been evolving on the Windows platform since Windows NT 3.1. You will find user roles in SQL Server and Exchange; role-based security is also part of Windows Server 2003. OpsMgr 2007 uses roles to determine whether a process (an instance of an executing program) is privileged, by checking the security context for a particular user or group.

Back when security was simple, a basic security implementation might just be to authorize users to access a particular application. This usually isn't enough, as you may want to define the type of access one has within that application. Think of that as different security roles.

A simplistic mapping of roles would be:

[User] has a [Role]

However, different roles often have overlapping tasks within an application, so now our mapping would be:

[User] has [Role] is allowed to execute [Tasks] made up of [Operations]

With this mapping (or model), an application can check if a given user has permission to execute a certain application and not worry about everything in-between.

Applying this to OpsMgr, a user role that grants authoring rights may limit its scope to a particular list of classes, while a user role that grants monitoring rights may limit that scope to a list of monitoring groups and views. In addition, specific tasks or operations are grouped into profiles.

A role is a combination of a profile (capabilities) and a scope (the breadth of data and objects one is able to access).

OpsMgr comes out of the box with a number of pre-defined roles. These built-in roles are associated with specific profiles, although they do not limit scopes. To narrow scope, you can create your own custom roles based on the built-in roles (with the exception of the Administrator profile, which cannot be customized). There is no limit to the number of user-defined roles you can create.

OpsMgr also incorporates Run As Profiles and Run As Accounts. A Run As Profile allow you to take a Windows user account and apply it to a specified profile in OpsMgr. Run As Profiles allow a management pack author to associate an identity other than the default action account with a particular module so it can run using the credentials of that identity. Run As Accounts typically map to Active Directory user accounts, and represent an identity that can be associated with a Run As Profile.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10