By incorporating an enterprise portal into their landscape, companies are typically looking to provide users with easy access to a range of applications, unify resources across the enterprise, and perhaps even conveniently share business information with partners, suppliers, and customers. But when the question of security comes up, things can get tricky: How to share vital information and applications with users inside and outside the company, simplify access for all involved, and still preserve the security of business data, systems, and processes? And does it mean undoing all the security measures now in place in each and every one of those applications?
Full Enterprise Portal Security, Without a “Rip and Replace” Approach
An enterprise portal collects business content and integrates business applications and services at the user level. With the main security features of SAP Enterprise Portal, there are two goals for shoring up the portal: maintain the current level of security in existing applications, and add further security without bogging down the system, slowing access, or reducing user efficiency.
To preserve the security in existing systems and the content they host, SAP Enterprise Portal security services tie into applications’ existing security services, whether they’re running on SAP Web Application Server or other technology platforms. The result is centralized security management for these applications — one of the added benefits of SAP Enterprise Portals.
Secure Communications Across the SAP Enterprise Portal Architecture
With SAP Enterprise Portal, administrators will find a number of options for securing each point of communication in the landscape. In a typical SAP Enterprise Portal architecture users access the portal via a standard Web browser using the HTTP protocol. SAP recommends placing a standard Web server (Microsoft Internet Information Server or Apache) in front of the SAP J2EE Engine running the Enterprise Portal server; it can act as a reverse proxy against the Internet and take over part of the load balancing responsibilities. Special Web server plugins for IIS and Apache are provided by SAP just for that purpose. The SAP Web Dispatcher is also an alternative here.
From the user’s Web browser to the frontend Web server, and on to the portal server, HTTP requests can be transported over the Secure Sockets Layer protocol using HTTPS URLs. SSL is the well-known Internet standard for secure communications, providing strong authentication and encryption functions using X.509 digital server certificates. With HTTPS, user’s requests and data are protected from eavesdropping and modification in transit.
The portal may require backend communications to support different user data stores for user management, authentication, and authorization. Backend connections are also required to integrate existing services and applications into a single, cohesive system. These communications can be carried out:
- Over secure connections using SSL.
- Via the SAP Remote Function Call (RFC) protocol — for SAP backend systems or applications running on the SAP Web Application Server. SAP RFC makes use of GSS API, plus an external security library for cryptography support.
When secure backend communications are combined with the appropriate network infrastructure, business communication is protected from attacks at the network and communication layers. Appropriate infrastructure design includes external and internal firewalls that separate network zones hosting user workstations, frontend Web servers and reverse proxies, the Enterprise Portal server, and backend systems. Using SSL and the GSS API ensures that all communication paths established and used with SAP Enterprise Portal are protected by strong authentication and encryption.
Authentication and Single Sign-On for Access by the Right Users
Each time a user attempts to access business-sensitive information, applications, or services through SAP Enterprise Portal, he or she will require user authentication. Depending on the infrastructure requirements there is a variety of authentication options for configuring your Enterprise Portal server.
- User ID and Password: The simplest authentication method, user ID and password, stores hash values of the user’s passwords in the user data persistence layer (relational database, LDAP directory, or SAP System). This method compares the hash value of the password, as entered by the user upon first access to the portal server, against the values stored. A form-based logon or basic authentication as provided by the Web browser can be configured for that purpose, and the password is transmitted over secure connections (as discussed above).
- Digital Certificates. If the users are already equipped with X.509 digital client certificates for accessing the Enterprise Portal server over HTTPS, the option of the SSL protocol provides a convenient and highly secure alternative for user authentication. This option doesn’t require any passwords to be transmitted to (or checked by) the Enterprise Portal server, but relies on the cryptographic keys and challenge-response protocol used by SSL.
- Current Authentication Infrastructure — SAP Web Application Server, SAP R/3, Windows, or Others. It is also possible to run the user’s initial logon against an existing authentication infrastructure, such as that provided by an SAP Web Application Server or SAP R/3, or by your Windows domain controller. Many more authentication options exist by using dedicated JAAS login modules provided by SAP Partner solutions.
After successful authentication at the portal server, Enterprise Portal users will need access to content and services as provided by components and systems integrated by the portal. Since these component systems retain their authentication controls, the portal has to find a way to transparently provide the logged-on user’s identity information. This feature is called “single sign-on” (SSO), and again, SAP Enterprise Portal offers a number of options for making secure access to multiple applications as transparent as possible:
- Single Sign-On via Digital Certificates or Windows Authentication. If the users already have X.509 digital client certificates or use Windows authentication, these also work as SSO mechanisms.
- Single Sign-On via SAP Logon Tickets. Single sign-on is supported via a ticketing mechanism, SAP Logon Tickets. For all SAP component systems, the portal server creates an SAP Logon Ticket after successful authentication and stores this ticket in the user’s Web browser as a non-persistent cookie. The ticket is protected by a digital signature and has a fixed timeout period. When used over secure connections, the SAP Logon Ticket achieves a level of security comparable to the user ID and password method for initial authentication. All SAP component systems must be configured once to trust the logon tickets created and digitally signed by the portal server. For non-SAP systems and applications, SAP offers a ticket verification library that can be integrated by the application vendor.
- Account Aggregation. For applications unable to take advantage of SAP Logon Tickets or another form of SSO — for example, for a legacy host application where modifications are too expensive — account aggregation provides yet another alternative. A user can be associated with a user ID and password for a certain set of applications. This is done by the portal administrator or by the user. When a portal user accesses an application that is mapped to a user ID and password, the portal server sends the required logon information on behalf of the user. Mapped user IDs and passwords are stored in encrypted form in the portal database.
Authorization with Resources for Appropriate Access Controls
Once authenticated, users in the SAP Enterprise Portal own different access rights as determined by the roles and groups assigned to them. With SAP Enterprise Portal 6.0, users have rights to the objects — i.e., folders, iViews, pages, and worksets — located in the Portal Content Directory (PCD). These rights are defined by Access Control Lists (ACLs). Users, roles, and groups are granted access by maintaining ACLs associated with the objects in the PCD, as well as for other unstructured information stored in the portal’s Content Management functions and repositories.
ACL maintenance is either done by a portal administrator or by the object owners themselves, depending on the object type. It can be simplified by using permission inheritance within the object hierarchy. For example, consider an iView: most portal pages will have at least one iView assigned to it. By default, if the iView object’s ACL is not maintained separately, that iView will automatically inherit the permissions as granted for the page. Similarly, if a role is granted permissions by an object’s ACL, all users assigned to this role inherit the permissions.
When users access applications and services hosted on other systems — such as SAP R/3, CRM, BI, and others — through the portal, the access controls of these systems are still valid. So, if a user accesses the SAP Customer Relationship Management (CRM) system through the portal, he or she will require appropriate authorizations in the CRM system. To manage these user roles, SAP Enterprise Portal offers role administration processes integrated with SAP component systems; role content and user-role assignments defined in the portal are automatically sent to the appropriate administrator’s inbox for authorization and further processing.
New and Improved User Management Support
For user management in earlier versions of SAP Enterprise Portal, it as possible to build and use an LDAP directory, or connect to an existing one. Now, SAP Enterprise Portal 6.0 comes with extended user management functionality provided by the SAP User Management Engine (UME). The UME provides further persistence options — namely, that relational databases and SAP Web Application Server can now serve as user data stores — which offer additional flexibility for managing user accounts and user attribute information.
Due to the flexibility of persistence adapters (separate software layers and interfaces built into UME) different user stores can also be used in parallel. Now, one can use different persistence adapters to partition different user accounts between different stores, such as internal users in an LDAP directory and external users in a database system. Or, for example, if it is necessary to keep email addresses and telephone numbers in the corporate directory while writing SAP-specific information to the portal database, the two sets of attributes can now be stored in different locations.
Security will not stand in the users way
If the users want to experience the integration capabilities and content management features of SAP Enterprise Portal, security will not stand in their way. In fact, SAP Enterprise Portal can actually extend the security services of the applications and systems integrated by the portal while providing simplified access (via single sign-on) over secure connections.
At the same time, access to portal content is subject to authorization checks, enforcing the role-based authorization concept of SAP component systems and ACLs for content administration and management — which will put administrators and IT teams at ease. Administrators will also find extended support for centralized user and role management leveraging existing user data stores in your enterprise in SAP Enterprise Portal 6.0.
For more details on portal security, please see “SAP Enterprise Portal 6.0: Security and User Management” available to registered SAP users at https://service.sap.com/ep or see the SAP Enterprise Portal documentation at https://help.sap.com.
Source: SAP Insider