Appboard/old/provisioning basics - Revision history

imported>Jason.nicholls at 18:40, 17 July 2014

2014-07-17T18:40:23Z

← Older revision		Revision as of 18:40, 17 July 2014
Line 1:		Line 1:
			{{DISPLAYTITLE:Provisioning Basics}}
			[[Category:AppBoard old]]
	Provisioning is how you create Users and Roles, and then provide the appropriate targeted information to them. This section details the concepts and definitions you will need to understand the basic concepts of provisioning.		Provisioning is how you create Users and Roles, and then provide the appropriate targeted information to them. This section details the concepts and definitions you will need to understand the basic concepts of provisioning.

imported>Jason.nicholls: moved Provisioning Basics to appboard/old/provisioning basics

2014-07-17T18:39:49Z

moved Provisioning Basics to appboard/old/provisioning basics

← Older revision	Revision as of 18:39, 17 July 2014
(No difference)

imported>David.moore: /* Roles */

2013-12-06T20:20:28Z

Roles

← Older revision		Revision as of 20:20, 6 December 2013
Line 51:		Line 51:


	When configuring the Roles to create in the system, first consider the Roles of an organization and decide which User(s) will be assigned to each Role. Each Role will control which tabs are displayed after a User successfully logs in. This is accomplished by the system administrator assigning ~~each view or stack~~ in the system to one or more Roles.		When configuring the Roles to create in the system, first consider the Roles of an organization and decide which User(s) will be assigned to each Role. Each Role will control which tabs are displayed after a User successfully logs in. This is accomplished by the system administrator assigning content in the system to one or more Roles.


	The hierarchical nature of Roles allows for subroles to be nested under Roles. If a subrole is assigned to a Domain or User, then the Domain or User inherits the assignments and permissions of the parent Role. However, the User(s) is only permitted to log in to the system in the subrole but not in the parent Role.		The hierarchical nature of Roles allows for subroles to be nested under Roles. If a subrole is assigned to a Domain or User, then the Domain or User inherits the assignments and permissions of the parent Role. However, the User(s) is only permitted to log in to the system in the subrole but not in the parent Role.


	=== Putting It All Together ===		=== Putting It All Together ===

imported>David.moore: /* Domains */

2013-12-04T20:22:31Z

Domains

← Older revision		Revision as of 20:22, 4 December 2013
Line 25:		Line 25:


	After creating each Domain, you will then assign one or more Roles to each Domain. These Roles will dictate the system content that is available to Users in that Domain. When a Role is assigned to a Domain, then all Users belonging to that Domain ~~inherent~~ the Role. New Users added later to the Domain would then automatically inherit these assignments.		After creating each Domain, you will then assign one or more Roles to each Domain. These Roles will dictate the system content that is available to Users in that Domain. When a Role is assigned to a Domain, then all Users belonging to that Domain inherit the Role. New Users added later to the Domain would then automatically inherit these assignments.

	=== Roles ===		=== Roles ===

imported>David.moore at 15:10, 26 November 2013

2013-11-26T15:10:25Z

← Older revision		Revision as of 15:10, 26 November 2013
Line 55:		Line 55:

	The hierarchical nature of Roles allows for subroles to be nested under Roles. If a subrole is assigned to a Domain or User, then the Domain or User inherits the assignments and permissions of the parent Role. However, the User(s) is only permitted to log in to the system in the subrole but not in the parent Role.		The hierarchical nature of Roles allows for subroles to be nested under Roles. If a subrole is assigned to a Domain or User, then the Domain or User inherits the assignments and permissions of the parent Role. However, the User(s) is only permitted to log in to the system in the subrole but not in the parent Role.


	~~=== Actors ===~~

	The term Actor refers to a specific User logging in to the system in a specific Role. An Actor is the combination of Domain, User, and Role. Most Users only have a single Role assigned, so they will always log in as the same Actor with the same permissions and views. However, some Users have multiple Roles assigned to them. A User with multiple Roles accesses the system as a separate Actor for each of his or her Roles.


	~~The following diagram illustrates the concept of actors for a single user:~~


	~~[[Image:Actor_Example.png\|thumb\|center\|300px\|Actor Example]]~~


Line 72:		Line 61:
	As you prepare to design your organizational structure, you should consider:		As you prepare to design your organizational structure, you should consider:

	* How ~~AppBoard Stacks and/or enPortal Views~~ should be organized ~~(Creating Content)~~		* How content should be organized
	* Who should have access to ~~each Stack or View that is created~~		* Who should have access to different content

imported>Jason.nicholls at 09:59, 28 August 2013

2013-08-28T09:59:02Z

← Older revision		Revision as of 09:59, 28 August 2013
Line 100:		Line 100:
	# Who can access what information?		# Who can access what information?
	# How will the information be used?		# How will the information be used?


	~~== Configuring the User Organization ==~~

	~~Once you have identified how you will be configuring the system, the following topics detail how to implement provisioning:~~

	~~[[AppBoard_Provisioning\|AppBoard Provisioning]]~~

	~~[[enPortal_Provisioning\|enPortal Provisioning]]~~

imported>Mike.berman: changes from peer review

2012-03-01T19:37:33Z

changes from peer review

← Older revision		Revision as of 19:37, 1 March 2012
Line 9:		Line 9:


	When ~~creating Users,~~ they must be grouped into one or more Domains. The primary purpose of a Domain is to provide an independent namespace of users. An unlimited set of Domains can be defined in a single system.		When users are created they must be grouped into one or more Domains. The primary purpose of a Domain is to provide an independent namespace of users. An unlimited set of Domains can be defined in a single system.


Line 22:		Line 22:


	As a first step in determining your User organization, determine if separate ~~accounts (~~Domains) need to be created so that users from one ~~account~~ would access the system independently from users in the other ~~account~~. For example, a managed service provider may want to group customers into separate Domains if they will be completely independent from one another in how they use the system.		As a first step in determining your User organization, determine if separate Domains need to be created so that users from one Domain would access the system independently from users in the other Domain. For example, a managed service provider may want to group customers into separate Domains if they will be completely independent from one another in how they use the system.


	After creating each Domain, you will then assign one or more Roles to each Domain. These Roles will dictate the system content that is available to Users in that Domain. When a Role is assigned to a Domain, then all Users belonging to that Domain inherent the Role. New Users added later to the Domain would then automatically inherit these assignments.		After creating each Domain, you will then assign one or more Roles to each Domain. These Roles will dictate the system content that is available to Users in that Domain. When a Role is assigned to a Domain, then all Users belonging to that Domain inherent the Role. New Users added later to the Domain would then automatically inherit these assignments.


	=== Roles ===		=== Roles ===

imported>Mike.berman: created page

2012-02-15T21:58:28Z

created page

New page

Provisioning is how you create Users and Roles, and then provide the appropriate targeted information to them. This section details the concepts and definitions you will need to understand the basic concepts of provisioning.

== Understanding the User Organization ==

This section provides guidelines on what to consider when planning the organization of the AppBoard/enPortal system.

=== Domains ===

When creating Users, they must be grouped into one or more Domains. The primary purpose of a Domain is to provide an independent namespace of users. An unlimited set of Domains can be defined in a single system.

A special Domain called System is reserved. This Domain is locked and can not be modified. It contains a single User named administrator. This User is always granted permission for all components in the system. You cannot add or remove Users from the System Domain.

Within a Domain, the user IDs must be unique. However, identical User IDs can exist in different domains.
The following diagram illustrates an example of domains and users:

[[Image:Domain_Illustration.png|thumb|center|300px|Domains and Users Example]]

As a first step in determining your User organization, determine if separate accounts (Domains) need to be created so that users from one account would access the system independently from users in the other account. For example, a managed service provider may want to group customers into separate Domains if they will be completely independent from one another in how they use the system.

After creating each Domain, you will then assign one or more Roles to each Domain. These Roles will dictate the system content that is available to Users in that Domain. When a Role is assigned to a Domain, then all Users belonging to that Domain inherent the Role. New Users added later to the Domain would then automatically inherit these assignments.

=== Roles ===

Roles are a hierarchical mechanism used to organize Domains and Users. Roles are the primary basis by which
capabilities are managed, preferences are stored, and content is secured. The following is an example of a Role hierarchy. Notice that the NOC role contains two subroles: Managers and Operators.

[[Image:RoleHierarchy.png|thumb|center|300px|Role Hierarchy Example]]

Individual Users or entire Domains can be assigned to a single Role or to many Roles.

Allowing Users or Domains to be assigned to multiple Roles provides each User the ability to switch his
or her interaction with the system. For example, Bob may need to access the system using the Role of
NOC Manager in order to access the necessary tools to isolate and replicate a problem. After
identifying the problem, he could switch to a Role of Administrator in order to access the rights
necessary to correct the problem.

When a Domain is assigned to a Role, all Users within the Domain are automatically assigned to the Role
as well. This allows administrators to add new Users to a Domain and have Roles automatically
assigned without having to take the time to assign individual security to the new User.

When configuring the Roles to create in the system, first consider the Roles of an organization and decide which User(s) will be assigned to each Role. Each Role will control which tabs are displayed after a User successfully logs in. This is accomplished by the system administrator assigning each view or stack in the system to one or more Roles.

The hierarchical nature of Roles allows for subroles to be nested under Roles. If a subrole is assigned to a Domain or User, then the Domain or User inherits the assignments and permissions of the parent Role. However, the User(s) is only permitted to log in to the system in the subrole but not in the parent Role.

=== Actors ===

The term Actor refers to a specific User logging in to the system in a specific Role. An Actor is the combination of Domain, User, and Role. Most Users only have a single Role assigned, so they will always log in as the same Actor with the same permissions and views. However, some Users have multiple Roles assigned to them. A User with multiple Roles accesses the system as a separate Actor for each of his or her Roles.

The following diagram illustrates the concept of actors for a single user:

[[Image:Actor_Example.png|thumb|center|300px|Actor Example]]

=== Putting It All Together ===

As you prepare to design your organizational structure, you should consider:

* How AppBoard Stacks and/or enPortal Views should be organized (Creating Content)
* Who should have access to each Stack or View that is created

Once you understand the content that will be available, you can set up the User organization to properly deliver that content to the appropriate Users. Complete the following steps to configure the system:

# Create Domains and Users
# Create Roles
# Create Content
# Assign Roles to Domains and Users
# Assign Content to Roles
# Create Look and Feel
# Assign Look and Feel
# Configure Login Page

The following steps provide a guideline in setting up a User organization:
* Use a company organization chart to help determine the users, domains, and roles
* Develop a series of questions to gather pertinent information
* Develop a matrix, form, or table that would help capture information you have gathered

With the aid of a company organization chart, the following questions will assist in ensuring a smooth and sensible implementation for your organization:
# What web-based information and resources are you delivering and to whom?
# Are you delivering to an internal or external location?
# How do you want this information displayed?
# Who can access what information?
# How will the information be used?

== Configuring the User Organization ==

Once you have identified how you will be configuring the system, the following topics detail how to implement provisioning:

[[AppBoard_Provisioning|AppBoard Provisioning]]

[[enPortal_Provisioning|enPortal Provisioning]]