Latest revision as of 15:43, 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. Within AppBoard content is assigned by Stacks to roles, and roles assigned to users and domains.

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. User level tokens always takes precedence over domain-assigned, or role-assigned tokens.

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

Roles & Stack Assignment

Roles

In AppBoard roles are primarily a grouping mechanism for assigning content. Content is assigned to the roles, and roles are assigned to domains and users.

Multiple roles can be assigned to a user, either directly or inherited through assignment to the user's domain. However, when a user logs into the system they only assume a single role. This is shown in the application header and a drop-down provided if the user has access to multiple roles. Switching roles will change what content is visible to the user.

As Roles can be managed internally but also externally with LDAP-based role adapters, or with custom integrations.

Role naming internal to AppBoard is actually stored as path, for example /portalAdministration, /cat and /cat/dog, however no inheritance is implied. Each role is unique and only provides access to the content directly assigned to it. Typically this is only evident when using LDAP-based role adapters where the role adapter name forms part of the path, such as /my_LDAP_role_adapter/roleA.

Overall roles are used for:

Content Assignment. One or more stacks are assigned to the role.
(enPortal) Content Assignment. One or more folders and channels assigned.
(enPortal) SSO Assignment. Similar to domain-assigned SSO tokens, these apply to a user if the role is assigned and the user is assuming that role.

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

Stack Assignment

Stack assignment is about provisioning content, in the form of one or more Stacks, to a particular role. In AppBoard this is a simple drag-and-drop process. The ordering of the Stacks determines the order the Stacks will be visible in the AppBoard Viewer.

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.

Managing Provisioning

Managing domains, users, roles, and how stacks are assigned to roles is managed manually via the Builder interface or handled via XML interface or custom JSP interface for automated and bulk-loading applications.

Manual management via Builder: This includes configuring LDAP managed Domains and LDAP role mapping.
Batch loading via XML: Loading domains, users, roles, and role assignments in bulk via XML files.
Custom JSP: i.e. build a custom web service for provisioning.

@@ Line 1: / Line 1: @@
 {{DISPLAYTITLE:Provisioning}}
 [[Category:AppBoard 2.5]]
+== 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. Within AppBoard content is assigned by ''Stacks'' to roles, and roles assigned to users and domains.
+If planning to use enPortal proxied content with AppBoard dashboards then also read over the [[enportal/5.5/admin/user_administration|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 [[appboard/2.5/builder/system_administration|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. User level tokens always takes precedence over domain-assigned, or role-assigned tokens.
+Refer to the [[appboard/2.5/builder/system_administration|System Administation]] documentation for managing Users within AppBoard.
+= Roles & Stack Assignment =
+== Roles ==
+In AppBoard roles are primarily a grouping mechanism for assigning content. Content is assigned to the roles, and roles are assigned to domains and users.
+Multiple roles can be assigned to a user, either directly or inherited through assignment to the user's domain. However, when a user logs into the system they only assume a single role. This is shown in the application header and a drop-down provided if the user has access to multiple roles. Switching roles will change what content is visible to the user.
+As Roles can be managed internally but also externally with LDAP-based role adapters, or with custom integrations.
+Role naming internal to AppBoard is actually stored as path, for example <tt>/portalAdministration</tt>, <tt>/cat</tt> and <tt>/cat/dog</tt>, however '''no inheritance is implied'''. Each role is unique and only provides access to the content directly assigned to it. Typically this is only evident when using LDAP-based role adapters where the role adapter name forms part of the path, such as <tt>/my_LDAP_role_adapter/roleA</tt>.
+Overall roles are used for:
+* Content Assignment. One or more stacks are assigned to the role.
+* (enPortal) Content Assignment. One or more folders and channels assigned.
+* (enPortal) SSO Assignment. Similar to domain-assigned SSO tokens, these apply to a user if the role is assigned and the user is assuming that role.
+Refer to the [[appboard/2.5/builder/system_administration|System Administation]] documentation for managing Roles within AppBoard.
+== Stack Assignment ==
+Stack assignment is about provisioning content, in the form of one or more Stacks, to a particular role. In AppBoard this is a simple drag-and-drop process. The ordering of the Stacks determines the order the Stacks will be visible in the AppBoard ''Viewer''.
+Refer to the [[appboard/2.5/builder/system_administration|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/2.5/builder|AppBoard Builder]] documentation.
+For information on including enPortal proxied content into AppBoard dashboards, refer to the [[appboard/2.5/builder/widgets/web_page|Web Page Widget]] documentation.
+= Managing Provisioning =
 Managing domains, users, roles, and how stacks are assigned to roles is managed manually via the Builder interface or handled via XML interface or custom JSP interface for automated and bulk-loading applications.
-All content is provisioned to roles. Within AppBoard this is done at the stack level and within enPortal this is via a hierarchy of folders and channels. If enPortal content is to be available to AppBoard users, or vice-versa, then the content ''must'' be provisioned to the role in the relevant part of the product.
-* [[Provisioning_Basics|Provisioning Basics]]: Understand the key concepts between domains, users, and roles.
 * [[appboard/2.5/builder/system_administration#Provisioning|Manual management via Builder]]: This includes configuring LDAP managed Domains and LDAP role mapping.
-* [[Batch_Loading_Users|Batch loading via XML]]
+* [[appboard/2.5/admin/provisioning/batch_loading|Batch loading via XML]]: Loading domains, users, roles, and role assignments in bulk via XML files.
-* [[Direct_Provisioning|Custom JSP]]: i.e. build a custom web service for provisioning.
+* [[appboard/2.5/admin/provisioning/custom_jsp|Custom JSP]]: i.e. build a custom web service for provisioning.

Edge Documentation

Appboard/2.5/admin/provisioning: Difference between revisions