Enportal/5.5/faq/custom solutions

Revision as of 05:09, 10 July 2014 by imported>Jason.nicholls (1 revision)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


This page answers Frequently Asked Questions (FAQ) about custom solutions for enPortal.

For FAQs about custom solutions in AppBoard, see the AppBoard Custom Solutions FAQ

Custom Solutions

Does enPortal Support SAML?

SAML is a standard for exchanging authentication and authorization data.

Edge has not specifically done SAML integration, but has done authentication integration with CAS and CA SiteMinder in the past (see SiteMinder question below).

It is possible to use SAML for authentication in enPortal/Appboard. Although SAML is not officially supported in enPortal/AppBoard, the products provide an extensible authentication system so that it could be approached as solutions work if needed.

There would be three scenarios that could apply to SAML support in enPortal/AppBoard:

  1. enPortal/AppBoard authenticating against a SAML Identity Provider (IdP). enPortal would be acting as a "Service Provider" (SP) in this scenario. This is something that Edge would potentially consider for inclusion in the product if the implementation could be made generic.
  2. enPortal/AppBoard authenticating on behalf of a user (principal), to perform SSO to a proxied application that is a SAML SP. This is going to depend on the back-end application itself - just like Single Sign-on (SSO) for any PIM.
  3. enPortal/AppBoard acting as an Identity Provider for other external service providers to authenticate against. This scenario is unlikely to be immplemented in enPortal/AppBoard.


Does enPortal Support Integration with CA SiteMinder?

Yes, enPortal integration with SiteMinder has been implemented as a custom solution.

Following are the basic data flow steps in the authentication integration:

  1. enPortal/Appboard integrates with SiteMinder's webagent. SiteMinder's webagent is hosted in an Apache server and enPortal/Appboard is configured to work with this Apache server.
  2. Once a user is authenticated by SiteMinder, its id is passed to the enPortal/Appboard through its forwarding Request. The id is in one of the header of HTTP Request.
  3. enPortal/Appboard is also talking directly to the LDAP server that SiteMinder is using to authenticate the user. enPortal/Appboard is using the id obtained in Step 2 to further get any additional information about the user, such as its Role (Group membership) information.

The content provisioning is still done in enPortal using the Role based model. Therefore, once a user logs in through SiteMinder, and obtains its Role information in Step 3, enPortal/Appboard will successfully display the provisioned content.

Can enPortal Manage 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 enPortal (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 enPortal, it best to explain where and how the passwords are stored within enPortal. enPortal makes use of a memory resident (or embedded) H2 database 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 enPortal GUI. This is due mainly to the persistent lock files of the database, and is part of the security measures used by enPortal. 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.