Appboard/old/faq
This page lists Frequently Asked Questions (FAQ) about enPortal and AppBoard. Each question contains answers and/or links to pages in the wiki with information on the requested topic.
Getting Started
How do I install AppBoard and enPortal?
- Download the AppBoard and/or enPortal software and license provided by your product vendor or distributor.
- Confirm that your server meets the System Requirements
- Install the free Java Development Kit (JDK) - available at http://java.sun.com/javase/downloads/index.jsp
- Follow the installation instructions:
How do I configure User and Roles?
To configure Users and Roles, log in to the Administration UI and follow the instructions for provisioning. Click the link below for detailed instructions:
How do I apply my own custom skins, themes, branding, and logos?
There are two theme settings that can control the overall style of the enPortal/AppBoard presentation to the user:
- enPortal Look and Feel (LAF) – This is the top banner that is presented to the user when logging into enPortal. By logging in to the enPortal administration interface, you can create multiple versions of this LAF and provision different LAFs to different roles.
- AppBoard Theme – This is the Theme configured in the “Theme Manager” under the AppBoard “Settings” menu. It manages the presentation of the AppBoard elements. For this theme, there is a single setting for the system and that applies to all Roles.
For additional detail on customizing the logos, banners, login pages, and branding, see the AppBoard Style Guide
Features
What applications are supported with pre-built integration modules?
For a list of Product Integration Modules (PIMs) currently available for AppBoard/enPortal, see Product Integrations. Each integration module provides a link with information or installations instructions for the integration.
By installing multiple integration modules, interfaces from these applications can be presented by enPortal side-by-side in the display to the User. AppBoard can also easily combine data from multiple sources into a Data Collection for display in one or more Widgets. AppBoard allows associations to be made between data sets coming from different sources to drive more meaningful data visualizations.
What is LDAP and how is it implemented?
LDAP is Lightweight Directory Access Protocol. It provides a service for storing and managing directories of items such as Users and Roles. It also provides simple interfaces for applications to access this information. This enables an organization to store all of this information in one centralized location. Many modern applications make use of the same concepts of Users, Roles, and Domains that are used in AppBoard/enPortal. It is not efficient to replicate the same lists of Users, Domains, and Roles in each application. Also, such lists would be difficult to maintain and keep in sync with one another.
As noted above, AppBoard and enPortal provide provisioning tools for managing Domains, Users, and Roles. However, some organizations already have an LDAP server in place to manage Users and Roles. In this case, AppBoard and enPortal can map to the existing LDAP configuration and rely on LDAP for externally managing this information.
Click the links below for detailed instructions on configuring LDAP:
Is Active Directory Supported for LDAP?
Active Directory is supported and has been used in several AppBoard/enPortal installations.
What support is available for load balancing and scalability?
The enPortal and AppBoard server can be deployed as a single standalone instance or in a clustered pair of servers with a front-end, hardware-based IP load balancer (e.g. Citrix, Cisco, F5, etc). The clustered option allows for both failover and scalability for large, mission critical environments.
The enPortal/AppBoard system is implemented as a web application architecture. It runs as a web application inside an Apache Tomcat Server, and accesses a JDBC accessible database, or clustered database system. The enPortal/AppBoard web application server scales horizontally by replicating on additional servers/platforms.
Horizontal scaling can be accomplished by adding new enPortal/AppBoard servers to the system in order to grow the capacity of the enPortal/AppBoard cluster.
A Load Balancer can distribute sessions to one or more enPortal/AppBoard nodes using any standard load balancing algorithm (e.g. Round-Robin, smallest load, fewest sessions, etc.). The only requirement is that the session affinity is maintained such that a single user is always routed to the same enPortal/AppBoard node during the full duration of the session. enPortal/AppBoard manages the session handling for all of the Tomcat processes and integrated applications within the enPortal/AppBoard component of the solution.
AppBoard provides an advanced data integration model that reduces the number of times back-end data sources must be queried. Role-based cashing and filtering means that each user only needs to fetch the data that is relevant for his or her dashboard. Settings for data polling and refreshing allow further management and control over the scalability of the system. Because AppBoard integrates at the data layer, a single query can bring data into AppBoard for display to a large numbers of users without burdening the back-end system as would be the case if users logged into the system directly.
For instructions on configuring Load Balancing, Scaling, or Failover, see Clustering and Failover.
Can I set up for high availability so that there is no single point of failure?
The solution can be configured to have high availability and integrated application round-robin/failover across multiple physical sites.
enPortal and AppBoard support one or more decoupled web application servers accessing a common user model stored in a database. There are three general server configuration options:
- Single server setup (no redundancy)
- Primary / backup server setup (redundancy but no load balancing)
- Clustered server option (redundancy with load balancing across N servers).
When multiple clustered application servers are used, the database must be external to the system (for single application server deployments, an embedded database may be used). Licenses can allow for either active-active or active-standby clusters. The load-balancer must be configured to provide session affinity / sticky sessions. Any number of application server instances may be used, and the scaling is linear as there is no crosstalk between the instances. For full system redundancy, an external load-balancer and an external, redundant SQL database must be provided.
What is the maximum number of client connections, data sources, or web integrations a single AppBoard server can reasonably manage?
The scalability of AppBoard is related to the number of queries per second and the total size of the cached records from all sources, while the scalability of enPortal is related to number of page views per second. AppBoard is able to cache data for any data source that is shared between multiple users (e.g. does not require user-specific credentials or parameters to query), and this greatly reduces the load on the AppBoard server and on the backend resources. For a 4GB Xeon server, a typical configuration for AppBoard having five shared data sources and five user-specific data sources updating once per minute, and a total size of 1 MB of data per user, AppBoard would scale to at least 150 concurrent users before memory or CPU utilization create bottlenecks. With the ability to share most or all data sources (which is typical of most deployment), this number can be much larger. enPortal is responsible for the web integrations, and the scalability of these are more variable and dependent on the complexity of the specific integrations used. Typical integrations allow between 5 and 25 integration page requests per second before CPU utilization becomes a choke point. With a typical user making three page views per minute and a conservative estimate of 5 integration requests per second, enPortal should handle 150 or more concurrent users on the configuration specified. The core user model supporting both enPortal and AppBoard can support effectively unlimited users who are not logged in.
Can I configure a "kiosk mode" where AppBoard will automatically rotate between Boards without any user interaction?
"Kiosk mode" or "Auto-rotation" is a common feature for AppBoard deployments on big screens in Network Command Centers. There are several options for implementing this. One option is to copy a Javascript customization file on to the AppBoard server, and then edit the file to list the Dashboards to cycle through and adjust the timing of the rotation.
For detailed instructions on implementing this customization, see Kiosk Mode.
Can I export dashboards for use outside of AppBoard?
There may be value in re-using an existing Stack for another project, to save the effort of re-creating the Stack from scratch. Stack Templates allow the AppBoard administrator to save all of the Boards, Widgets, and settings for a Stack to an external XML file so that they can be imported into another project.
For instructions on using this feature, see Stack Templates.
Is multi-tenancy supported?
Multi-tenancy is the concept of supporting data for multiple customers in the same system. It is an important feature of AppBoard/enPortal, because it allows a company such as a Managed Service Provider to create a single solution to apply across an entire customer base. This is more efficient than creating a separate system for each customer.
AppBoard/enPortal supports multi-tenancy through the concept of Domains. When Users log in to the dashboards, in addition to providing their username and password, they also supply a value for the Domain variable, which can be used for securely segmenting the data by Domain. This ensures that users are only seeing data they are authorized to see within that Domain. AppBoard/enPortal applies multi-tenant support to underlying systems that do not natively support it, and provides the ability to show secure, segmented views of information from the same application to different users.
Can I view my dashboards on mobile devices?
AppBoard provides support for Apple iOS, Android, and Blackberry Playbook mobile devices through native applications. These native apps provide mobile-centric views of the same content that is available through the desktop web interface. The mobile client uses the very same configuration and data as the desktop client and therefore requires no extra configuration but creating a mobile-specific view of data can provide extra benefits. The mobile clients support a wide range of the widgets in AppBoard, but some are not available due to device, screen size, and licensing limitations.
More detail on mobile features and configuration is available at AppBoard Mobile.
Security
What is Single-Sign and how is it implemented?
Single Sign-on (SSO) is a feature of AppBoard and enPortal where a User's credentials are securely stored in the system. This allows Users to access and display information from back-end applications without having to manually log in to each of these applications. By allowing administrators to assign authentications to Roles, Domains, and Users, the "single login" capability eliminates the need for users to log in separately to integrated resources displayed in the web interface. If no credentials exist for a User in an integrated application, the User can log in to the application and AppBoard/enPortal will capture the credentials for future use.
Single Sign-on tokens are managed by the AppBoard/enPortal administrator in the Integration Management section of the Administrator UI.
How is CAC/PKI authentication configured?
Common Access Card (CAC, also referred to as PKI) authentication is a special custom login mechanism used by certain organizations, including the United States Department of Defense. It restricts access to certain computer systems, such that only Users with an appropriate card can log in to the system.
enPortal and AppBoard support CAC/PKI authentication through the use of an add-on authentication module. This module can be implemented as long as the following requirements are satisfied:
- The client has the necessary middleware installed to support the PKI infrastructure, providing the ability to read the CAC card information and submit the login details to the server.
- A valid SSL server certificate is installed on the AppBoard/enPortal server and AppBoard/enPortal is running with the HTTPS protocol.
- The AppBoard/enPortal server has connectivity established, via Firewall exceptions, to an Online Certificate Status Protocol (OCSP) Responder.
- The root CA and Intermediate CAs are collected and packaged for the custom PKI module to use for communicating with the OCSP Responder to validate a User’s certificate.
How Are Usernames and Passwords Stored?
During an active session, credentials are stored in memory for use in authenticating to back-end integrated applications. Credentials are stored in a reversible form, so they can be submitted to integrated applications on behalf of the User. These credentials are stored using AES encryption. Credentials for accessing AppBoard/enPortal are stored using a salted hash per database security best practices.
Users cannot extract or access usernames or passwords for back-end applications. The client never receives any version of these credentials. These are only communicated directly between AppBoard/enPortal and the back-end application.
Does AppBoard/enPortal encrypt communications between the client and server?
HTTPS can be enabled for either or both of (a) browser to AppBoard/enPortal communications, and (b) AppBoard/enPortal to back-end application communications. This option requires the installation of an SSL certificate on the AppBoard/enPortal server.
enPortal serves as a proxy and reverse proxy for all applications it manages. All communications between the client and the portal pass through a single port, so only one port needs to be opened in the server firewall, regardless of how many applications are being proxied. enPortal manages all communications to and from the back-end applications, which are never exposed to the outside world.
Does AppBoard/enPortal provide protection against cross-site scripting attacks?
AppBoard/enPortal provides comprehensive protection against cross-site scripting attacks. All aspects of the HTTP communication are tested by the proxy, including request, headers, and body. Captures cause display of HTTP 500 responses. Updates to the output encoding scheme are also implemented to improve system efficiency and to eliminate cross-site scripting attacks. The default behavior is to deny requests that contain malicious characters if the page that initiated the request is not from the AppBoard/enPortal server.
How is the content which is accessed and rendered inside AppBoard/enPortal secured?
AppBoard content is secured primarily at three levels. On the user interface side, the set of visual components that a given User can access is determined by the content provisioning provided by the user model. A User will see the set of dashboard Stacks (seen as tabs) that have been assigned to its Role(s), which in turn can be assigned directly to the User or to the Domain of the User. The data sets (called Data Collections) that drive each visual component can be secured by applying filters on the AppBoard server to allow or prevent individual records from being presented to an end user (e.g. filter on company name, where company name is pulled from the User’s LDAP attributes). Finally, the connections to the remote data sources can be secured by specifying User- or Domain-specific credentials for the connections (e.g. a database connection may require a username and password that is unique to each Domain/customer account).
Technologies
Is the development platform/framework based on industry standards and does it have an open architecture?
AppBoard visualizations are based on Adobe Flex, a powerful, open source application framework for building mobile, web, and desktop applications. Flex offers stunning, dynamic visualizations that provide cross-platform support (mobile device/browser/desktop) and server integrations Java™, Spring, Hibernate, PHP, Ruby, .NET, Adobe ColdFusion®, and SAP using industry standards such as REST, SOAP, JSON, JMS, and AMF.
Is Adobe dropping support for Flash? Will AppBoard support HTML 5?
Adobe continues to release and support Flash, and has a published roadmap of future releases and continued platform support. Detailed information is available at http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html.
AppBoard utilizes a combination of Flash and HTML in AppBoard Builder (the administration UI) and AppBoard Viewer (the end-user presentation). Users interact with Flash content through the AppBoard Viewer. The Viewer presents a combination of both Flash and HTML-based Widgets to the User. It is important to understand future plans regarding the use of both Flash and HTML 5. As the HTML 5 feature set and cross-browser compatibility mature and demonstrate viability in this industry space, AppBoard's roadmap includes the incorporation of support for an HTML 5 AppBoard Viewer. Edge will continue to evaluate applicability of HTML 5 and other rapidly emerging web-based technologies to support an even broader range of product features in the future.
The AppBoard architecture and development teams continuously evaluate new technologies and standards for incorporation into AppBoard. How these technologies are incorporated into the product is based on several factors that include the maturity and commercial viability of the technology and customer/partner demand. In the case of HTML 5, there is a three-phase support plan for the incorporation of the technology into AppBoard. Phase one, the incorporation of HTML-based Widgets into AppBoard, has already been performed and will continue through the life of the product. Phase two, the delivery of an HTML 5 AppBoard Viewer is on the AppBoard product roadmap but is dependent, in part, on the expansion of the HTML 5 component feature set, more unified support for HTML 5 features across vendor browsers, and customer/partner demand. Phase three, the delivery of an HTML AppBoard Builder, has the same fundamental requirements as phase two from a technology perspective but is especially dependent on the continued expansion and maturity of the HTML feature set.
enPortal does not utilize Adobe Flash or Flex.
What integration points and communication protocols are supported?
AppBoard has out-of-the-box support for integrated data from any database with a JDBC driver, SOAP, RESTful, and other XML web services that can be transformed via XSLT and retrieved via HTTP or HTTPS, CSV or other delimited flat files, XLS spreadsheets, and various vendor data sources (see complete list for vendor support). AppBoard data is accessed from the client via BlazeDS. enPortal can present HTML or XML content that is retrieved via HTTP or HTTPS and is presented to the client browser via HTTP or HTTPS. Configuration files are in XML.
AppBoard's data adapter framework is agnostic as to the type or function of the data. This enables AppBoard to treat any external system as a Data Source; whether it's commonly considered a data repository or not. AppBoard ships with a Facebook data adapter. AppBoard also ships with an XML based web services data adapter that allows for integrations with most XML based APIs (and there are thousands of systems that use XML APIs).
In addition to the pre-built enPortal PIMs and AppBoard adapters, the AppBoard/enPortal server provides Java APIs for customizing authentication methods, session management, logging, and triggering actions from server events. AppBoard provides further Java APIs for creating custom data adapters. AppBoard provides Flex (for Adobe Flash) APIs for integrating custom visual components. enPortal provides XML APIs for creating custom web integrations.
What mapping technologies are accessible for an end user?
The included Flex Mapping Widgets are: Google Map (HTML version also available), ESRI, ILOG Elixir (Vector) Maps. Edge AppBoard includes the AppBoard Flex SDK supporting both Flex and HTML 5 based widgets. HTML 5 widgets are supported through the standard ActionScript to JavaScript External Interface methods. Flex mapping components can be integrated by creating a wrapping class for the existing Flex component to implement the simple Widget interface that communicates with the container and provides functions for setting the data source for the underlying Flex component. This custom Flex widget is integrated as described above. This has been demonstrated in Flex Widget wrappers for MapQuest, ESRI, and Google Earth.
Compliance
To what extent does AppBoard/enPortal support compliance standards?
IPv6 (Internet addressing protocol)
We have done some preliminary testing and development of enPortal under various potential scenarios for supporting IPv6. enPortal does not currently support IPv6.
When we talk about requirements for IPv6, this means knowing which segments of the enPortal system will need to support IPv6. For example:
- Client access (browser/apache)
- Portal server
- Database
- Back-end applications
As an example, if you needed a system that supports IPv6 for client access, but remains IPv4 for the other segments, this could be delivered sooner than a system that required full IPv6 support for all of the above components. Likewise, if your segments are scheduled to convert to IPv6 at different stages, we could potentially provide a series of enPortal upgrades that would support those stages.
Although we do not yet have a build that supports IPv6, if you can provide some information on which are the highest priority segments we can prioritize testing and development of those areas to target the earliest delivery of the product that will meet your needs.
JSR 168 (Java portlet specification)
Integration of JSR168 portlets will be seamless, once support for JSR168 is introduced in a future version of enPortal. Prior to enPortal 5.0, JSR 168 portlets could be integrated into enPortal by running the portlets in a separate portal and proxying the portlets as generic web application content.
The enGage engine provides a JSR 168 compliant portlet module. This module can be installed on other compatible frameworks and allows them to leverage the library of PIMs available as embedded portlets.
JSR 286 (Java portlet specification)
There are two possible contexts of this question:
- Can JSR 286 portlets be installed in our container?
- No we are not a portlet container.
- Do we expose our interfaces as JSR 286 Portlets to be installed in another container.
- No we do not have our system packaged as a portlet.
- We do have our interface packagable as a war; but this is expected to be installed in our Turnkey Tomcat container.
- If we were to add the markers for the portlet spec we would need to do this most likely for each portlet container.
508 (Accessibility)
enPortal functions as a host for other applications and thus relies on the content from those applications being 508 compliant. However, the custom look and feel that enPortal can provide may be designed to be 508 compliant. AppBoard is not yet fully 508 compliant; however, widgets may be configured using shapes and text in addition to color to enable color-blind individuals to easily determine the meaning of various status symbols and indicators.
FIPS 140-2 (Cryptography standard)
AppBoard and enPortal use encryption algorithms that are FIPS 140-2 approved, but have not been formally FIPS 140-2 certified. In conjunction with AppBoard and enPortal, providers such as Java, Apache, OpenSSH would need to be certified before formal certification could be achieved.
Custom Solutions
SharePoint is an ASP.NET based solution, so there is no way that AppBoard could run in same process. You could run AppBoard on the same server, but there is no advantage to doing so over hosting on another server. The integration would be the same.
AppBoard views could be presented inside of a custom web part for SharePoint (like J2EE widget). The web part simply would reference AppBoard via some URLs and parameters that have access credentials and desired Stacks. This would be similar to how any portal could integrate AppBoard content. This approach is not yet polished, but it is something that has been done before. It is actually easier to integrate AppBoard into SharePoint than it would be to integrate a SharePoint web part into enPortal/AppBoard, because AppBoard's session management is much easier than .NET's. However, it would require custom ASP.NET development to achieve. Some Sharepoint experience would help with this, although there is not too much involved in making a web part.
Managing Password Rotation
Our customer uses Enterprise Password Vault module in Cyber-Ark's Privileged Identity Management (PIM) Suite for managing password rotation. If we want to integrate all password rotation into AppBoard (such as Active Directory accounts for LDAP authentication, and passwords in Data Sources), is it possible for other tools/scripts to automate the process?
In order to consider the use of the third party application Cyber-Ark to manage your password rotation needs within AppBoard, it best to explain where and how the passwords are stored within AppBoard. AppBoard makes use of a memory resident (or embedded) H2 sql server for some of its internal workings. One of these internal workings is password storage for the overall system and data source configurations. The only interface into the DB is through the AppBoard GUI. This is due mainly to the persistent lock files of the database, and is part of the security measures used by AppBoard. An interface could be constructed via JSP to allow a third party to interact with passwords within the database.
Can I integrate custom-built web applications and legacy applications that are not web-based?
AppBoard and enPortal integrate with custom-built web applications at the data layer and the web GUI layer. enPortal's Content Retrieval Service is designed to easily integrate web applications, and many integrations require minimal effort to build. The default rules support most applications that use basic authentication and do not use javascript to dynamically create content on the client. For such applications, integration can be achieved in minutes. If custom authentication support is required, such as typical form-based authentication, this can often be achieved in under a day or two by a web developer (knowledge of HTML and Javascript) who has taken the integration class. If the application requires additional rules to allow it to work within a portal view (such as preventing targeting the top frame), 1-2 days of work from a trained web developer may be required. In less common instances, it may take a trained web developer approximately a week of effort or advanced consulting services from Edge to integrate an application.
AppBoard and enPortal are also able to integrate with legacy applications that are not web-based via data adapters. Integration with non-web application GUIs is via an integration module (PIM) to Oracle/Sun Secure Global Desktop, a product that enables non-web applications to be accessed from any Java-enabled web browser.
