Appboard/2.4/admin/provisioning: Difference between revisions

imported>Jason.nicholls
No edit summary
imported>Jason.nicholls
No edit summary
Line 7: Line 7:
AppBoard and enPortal share much of the same provisioning model under the covers but actual assignment of content to roles differs. If planning to use enPortal proxied content with AppBoard dashboards then also read over the [[enportal/5.4/admin/user_administration|enPortal User Administration]] documentation.
AppBoard and enPortal share much of the same provisioning model under the covers but actual assignment of content to roles differs. If planning to use enPortal proxied content with AppBoard dashboards then also read over the [[enportal/5.4/admin/user_administration|enPortal User Administration]] documentation.


== Domains and Users ==
== Domains & Users ==


== Domains ==
== Domains ==
Line 30: Line 30:
* (enPortal) LAF Assignment. With enPortal each domain can be assigned a different look-and-feel to the system-wide default.
* (enPortal) LAF Assignment. With enPortal each domain can be assigned a different look-and-feel to the system-wide default.


Refer to the [[appboard/2.4/builder/system_administration|System Administation]] documentation for managing Domains within AppBoard.


== Users ==
== Users ==
Line 44: Line 45:
* (enPortal) SSO Assignment. Assigning SSO tokens at the user level can be done explicitly by the administrator or when prompted by the system and a user enters their application credentials. If a token matches the same target as a token assigned at the domain level, then the user level token takes precedence.
* (enPortal) SSO Assignment. Assigning SSO tokens at the user level can be done explicitly by the administrator or when prompted by the system and a user enters their application credentials. If a token matches the same target as a token assigned at the domain level, then the user level token takes precedence.


= Roles =
Refer to the [[appboard/2.4/builder/system_administration|System Administation]] documentation for managing Users within AppBoard.


[[Image:Domain_Illustration.png|thumb|center|300px|Domains and Users Example]]
= Roles & Stack Assignment =


== Roles ==


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.
Refer to the [[appboard/2.4/builder/system_administration|System Administation]] documentation for managing Roles within AppBoard.


== Stack Assignment ==


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.
Refer to the [[appboard/2.4/builder/system_administration|System Administation]] documentation for managing Stack Assignment within AppBoard.


=== Roles ===
= Creating Content =


Roles are a hierarchical mechanism used to organize Domains and Users. Roles are the primary basis by which
Creating content in AppBoard is through using the ''Builder'' and adding top-level Boards (Stacks), drill-down Boards, and widgets for these Boards.
capabilities are managed, preferences are stored, and content is secured.  The following is an example of a Role hierarchy. Notice that the <b>NOC</b> role contains two subroles: <b>Managers</b> and <b>Operators</b>.


The assigned Stacks determine the top-level navigation items in the ''Viewer'', while the widget actions determine the actual flow through the Boards. Only Boards that belong to assigned Stacks are reachable though.


[[Image:RoleHierarchy.png|thumb|center|300px|Role Hierarchy Example]]
For more information on building content refer to the [[appboard/2.4/builder|AppBoard Builder]] documentation.


 
For information on including enPortal proxied content into AppBoard dashboards, refer to the [[appboard/2.4/builder/widgets/web_page|Web Page Widget]] documentation.
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
<b>NOC Manager</b> in order to access the necessary tools to isolate and replicate a problem. After
identifying the problem, he could switch to a Role of <b>Administrator</b> 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 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.
 
=== Putting It All Together ===
 
As you prepare to design your organizational structure, you should consider:
 
* How content should be organized
* Who should have access to different content
 
 
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?

Revision as of 06:26, 16 July 2014

What is Provisioning?

For a User to log in to AppBoard and view content, an Administrator must first create the User in the system and then assign appropriate content to that User. Provisioning is the means of configuring these users, domains, roles, content, and assignments between users and roles, and content and roles.

AppBoard and enPortal share much of the same provisioning model under the covers but actual assignment of content to roles differs. If planning to use enPortal proxied content with AppBoard dashboards then also read over the enPortal User Administration documentation.

Domains & Users

Domains

All Users in AppBoard belong to a Domain. It's the combination of user + domain that identifies a unique user to the system. This also implies that within a domain the user name must be unique.

In some deployments there may only be a single domain and this can be completely hidden from the end-users by modifying the login page to pre-fill and hide the domain input. In other deployments it is a desirable feature to provide multi-tenancy and have users grouped into appropriate domains to match the tenants of the system.

The system includes a special System domain with the default user administrator that has the portalAdministration role assigned. This domain is read-only so no users can be added or deleted. The portalAdministration role can be assigned to other users however, and the default account can be locked if so desired.

AppBoard itself supports any number of additional domains however the number allowed depends on the software license.

Users within a Domain can be managed internally to AppBoard, or can be managed externally such as with integration to an external LDAP-based service like Microsoft Active Directory.

In addition, Domains can be used for various assignments / configurations that apply to all users within that domain:

  • Session Limits. For example only 2 concurrent sessions at a time for a particular domain.
  • Password Policies. Enforce a policy on users within this group. Please note this may not apply if using external authentication.
  • Role Assignment. Assignment of roles to a domain means that all users within the domain have that role.
  • Domain scoped Session Variables.
  • (enPortal) SSO Assignment. Assignment of single sign-on (SSO) tokens at the domain means that all users within the domain will use those SSO credentials for the specified targeted proxied applications.
  • (enPortal) LAF Assignment. With enPortal each domain can be assigned a different look-and-feel to the system-wide default.

Refer to the System Administation documentation for managing Domains within AppBoard.

Users

As mentioned above, a combination of user + domain identifies a unique user to the AppBoard system. Authentication for all users of the domain depends on the domain, either internally or via external authentication such as with LDAP-based systems.

When a user is logged into AppBoard they must have at least one role assigned, and content assigned to that role, in order to access the system. If multiple roles are assigned then the user can choose which role they want to be via a drop-down in the application header. See the Roles section below for more information.

The following assignments and configuration are available at the user level:

  • Account Lock: administrator is able to lock/unlock specific accounts
  • Role Assignment. Assignment of roles to a user is in addition to any roles assigned at the domain level.
  • User scoped Session Variables.
  • (enPortal) SSO Assignment. Assigning SSO tokens at the user level can be done explicitly by the administrator or when prompted by the system and a user enters their application credentials. If a token matches the same target as a token assigned at the domain level, then the user level token takes precedence.

Refer to the System Administation documentation for managing Users within AppBoard.

Roles & Stack Assignment

Roles

Refer to the System Administation documentation for managing Roles within AppBoard.

Stack Assignment

Refer to the System Administation documentation for managing Stack Assignment within AppBoard.

Creating Content

Creating content in AppBoard is through using the Builder and adding top-level Boards (Stacks), drill-down Boards, and widgets for these Boards.

The assigned Stacks determine the top-level navigation items in the Viewer, while the widget actions determine the actual flow through the Boards. Only Boards that belong to assigned Stacks are reachable though.

For more information on building content refer to the AppBoard Builder documentation.

For information on including enPortal proxied content into AppBoard dashboards, refer to the Web Page Widget documentation.

Retrieved from "http://ab.edge-technologies.com/docs/index.php?title=Appboard/2.4/admin/provisioning&oldid=7319"