Enportal/5.5/faq/security


This page answers Frequently Asked Questions (FAQ) about enPortal and AppBoard security.

Security

What is Single-Sign and how is it implemented?

Single Sign-on (SSO) is a feature of enPortal where a User's credentials to integrated applications are securely stored in the enPortal 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, this "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 manually log in to the application and enPortal will capture the credentials for future use.

Single Sign-on tokens are managed by the enPortal administrator in the Provisioning 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.
    • Note that enPortal can be configured to failover to alternate OCSP responder URLS. To configure this feature, update the [INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties to contain:
ocsp.responder.0=<url>
ocsp.responder.1=<url>
where '<url>' is replaced with the URL corresponding to your OCSP Responder URL. enPortal will each URL in sequence until it finds an available responder, or has tried all specified responders. Ensure that the list of responders starts with "0" and increments by 1 for each listed. If it doesn't find ocsp.responder.0 it will try to look for the prior config 'ocsp.resonder' and if that fails it will default to "http://ocsp.disa.mil".
  • 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 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 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.

More information is available on the enPortal Security page.

How is the content which is accessed and rendered inside AppBoard/enPortal secured?

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 only the tabs of content 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).

Is enPortal or AppBoard vulnerable to the SSLv3 (POODLE) exploit?

This vulnerability is a problem with the SSLv3 protocol itself. It does not matter the implementation, so Tomcat, Apache, and any other web server that supports HTTPS could be vulnerable. The solution is to disable SSLv3 support in Tomcat and only allow TLS connections. The browsers are also doing the same by releasing or planning to release updates that completely disable SSLv3 to avoid this issue. We have resolved this issue in our enPortal/AppBoard v5.5.1 / v2.5.1 release by ensuring that only TLS is enabled. For releases prior to v5.5.1 / v2.5.1, the administrator can disable SSLv3 by doing the following steps:

  1. Edit [INSTALL_HOME]/server/conf/server.xml
  2. Find the line with: ... SSLEnabled="${http.ssl}
    • (this should be line 80 in a default server.xml)
  3. Add below this line a new line with:
    • sslEnabledProtocols = "TLSv1,TLSv1.1,TLSv1.2"
  4. Restart enPortal/AppBoard
  5. Test to see whether SSLv3 is enabled/disabled before and after using the openssl client and specifying the protocol, by a procedure sch as the following:
    • $ openssl s_client -connect enportal_server:443 -ssl3

With SSLv3 enabled, you will get a telnet type cursor waiting for you to issue a HTTP request. If it is properly disabled, then you will get a handshake failure and returned to the command prompt.

Retrieved from "http://ab.edge-technologies.com/docs/index.php?title=Enportal/5.5/faq/security&oldid=7265"