One of the buzzwords you might have come across lately in Enterprise Security Management is "identity management." This article will explain what it means, what you should take into consideration when thinking about a project involving identity management, what benefits you can gain from it, and how SAP helps you support identity management within your system landscape.
07 Jun 2005
What is Identity Management?
Well, what is identity management? Identity management deals with managing the entire lifecycle of a user, also known as an "identity." This begins with creating the user account and moves on to provisioning the user to different backend systems, including giving the user the corresponding access rights. Change management accompanies the process whenever a user changes jobs or positions, which usually results in different system access and different access rights. The user management lifecycle ends when a user no longer works with or for the company and thus all of his/her accounts must be terminated or de-provisioned.
Usually this lifecycle is accompanied by a more or less complex workflow support, starting with user self-registration, approvals by managers and key users for roles and system access, administrators being notified to create or change a user, as well as user information roll-out to the new or changed user.
But user lifecycle management and specifically the provisioning of user accounts and attributes is only one piece of identity management. The second, often forgotten, piece, is access management. How do you authenticate users? What mechanisms do you use to have users provide credentials? How does this change in B2B/collaborative scenarios? Do you want to set up a company own Public Key Infrastructure (PKI), or do you want to rely on a Trust Center Service? What Single Sign-On (SSO) mechanisms are available? Do you have rules or policies that define the user’s access?
Access management deals with authentication mechanisms and their management as well as authorization management. We will first explain the identity management piece and then delve into the details of access management.
What are the main points to consider when referring to the User Management piece within Identity Management?
One of the most important points to consider, if not the most important of all, is a central repository - usually in the form of a directory service. Advantages of holding all users in a central repository are that you reduce maintenance significantly and increase data quality and consistency. Instead of maintaining user master data separately in each of the various backend systems (try to come up with a list of how many different systems you have that need user master data!), resulting in a high administrative effort and data inconsistency, you maintain the user master data only once and use the provisioning mechanisms to an from the repository. This will ensure that user master data across your entire landscape is consistent, in turn increasing security.
Directory services are the most widespread repository because they support an accepted and developed standard to access the directory called "LDAP" (Lightweight Directory Access Protocol). Loads of backend systems support LDAP, so you can use user synchronization or provisioning to and from the directory service. Not only does this allow central repositories in the form of a directory service to store and provision users, you can also hold user credentials in the form of User ID and Password or X.509 Certificates for authentication. In addition, you can store group or role assignments, which often represent the corresponding backend system access.
SAP supports the mass synchronization between SAP systems and a directory service with SAP Web Application Server 6.10 and higher releases. For a list of certified directory vendors, see SAP Security Partners - Directory Integration on SAP Service Marketplace. You will find cookbooks on how to configure the directory integration at SAP Security -> Security in Detail -> Identity Management -> Directory Integration. Not only does SAP help you synchronize users between an SAP system and a directory service, but you can also upload HR master data from an SAP HR system into a directory. A cookbook on how to configure this can be found under the link above.
User Management Engine (UME)
SAP Enterprise Portal 6.0 (SAP EP) allows the directory to be the user store for the portal. Thus, no user mass synchronization is needed between the portal and the directory, but the portal’s user management - the so-called User Management Engine (UME) - will read and write user master directly from the LDAP server. The UME is also used as the user management for web applications developed on the J2EE Engine stack on SAP Web Application Server as of release 6.30.
What are the recommended landscapes for identity management including SAP systems?
Central User Administration (CUA)
If you have backend systems on SAP 4.6c and lower releases, we recommend that you configure a Central User Administration (CUA) central in SAP Web Application Server (highest release possible) stand-alone. Gather all your user master data for central administration for SAP backends here and use this to minimize administration and keep user master data consistent. Learn how to configure CUA at SAP Security -> Security in Detail -> Identity Management -> Centralized Administration. Use the mass synchronization between SAP Web Application Server (your CUA central) and a directory service to make your SAP user master data available for provisioning to other non-SAP backends via the LDAP server, or for user access to the SAP EP 6.0 (also for the SAP EP 5.0).
If all your SAP backends are based on SAP Web Application Servers 6.10 or higher releases, you can use the mass synchronization to an LDAP Server directly without CUA, although we strongly recommend that you use a CUA too.
If you wish to keep user master data at separate stores (we often find this when user master and security administration is spread organizationally across a company for the sacrifice of high user administration.), we recommend that you use a Central User Administration to minimize user administration for your SAP systems in SAP Web Application Server 6.20 or higher releases. For your non-SAP systems you can then have one or multiple directory servers for instance. The advantage you gain from this landscape is when you implement SAP EP 6.0 - the User Management Engine of the Portal will leverage your different user stores. SAP EP 6.0 allows for multiple user stores in parallel. These can be an SAP ABAP stack for user management on SAP Web Application Server 6.20 or higher releases, a directory and a database. The list of certified repositories can be found in the Product Availability Matrix (PAM) on SAP Service Marketplace. In short, SAP EP 6.0 allows for what is known as "user partitioning." Parts of your user master data can reside in an SAP ABAP stack 6.20 or higher, and parts in one or more LDAP servers. You can immediately start implementing and using your portal without first putting together a project to centralize all users.
What about Workflow Support?
SAP EP 6.0 offers a simple user self-registration that allows users to self-register and informs an administrator that user maintenance has to be performed on a new user. The ad-hoc workflow capabilities of the portal allow you to configure more complex and sophisticated workflows that can support you in user management and approval/rejection of users and system access and/or role assignment.
In the first part of the article, we have discussed features and functions of the user management lifecycle, how user master data is provisioned, how a central repository helps you, etc.
Let us now focus on the access management piece of identity management. How do users get authenticated and gain access rights to backend systems?
Term Clarifications for Access Management
First let’s get some terms clear that are often mixed and misunderstood.
Authentication means what mechanism is provided by a user to get authenticated or to get his/her identity verified to access a system.
Single Sign-On means what options are available to have a user authenticate only once and get access to various different backend systems including SAP, non-SAP, etc. The implementation of Single Sign-On reduces your security administration significantly as you only have to roll-out one password instead of many. And it increases security as end-users do only have to memorize one password instead of many.
External Authentication means that you want to delegate the authentication against an external mechanism not native to your system that overrules your system's user authentication. Most often this is done with authentication via LDAP servers, where the credentials of a user are stored, or if a strong authentication mechanism has to be incorporated that is usually offered by specified vendors in this area. A very good example of this latter function is biometric authentication, where a user’s credentials are verified via biometrics like iris scans, fingerprints, or voice recognition.
What authentication mechanisms are available? In its simplest form a user provides a user ID and password to gain access to a system. This is supported by all SAP systems. When this authentication is done via an HTTP connection it is called basic authentication. This means that you use the browser’s standard pop-up asking for the user’s credentials. If this standard pop-up window does not fulfill your requirements for a web-based log on screen, you can use so-called "form-based authentication," where you develop your own logon screen asking, for example, not only for user ID and password, but for an email address, age, or any other information you would like the user to provide. In addition, you can put your company’s logo on the form-based authentication. SAP supports basic and form-based authentication for web applications with the J2EE Engine on SAP Web Application Server. Form-based authentication is also supported in ABAP with the SAP Web Application Server 6.20 and higher releases.
The user's password is stored as a hash value in the system’s database. A hash algorithm is a one-way mathematical function that encrypts data. The one-way indicates here that with the current computer power and algorithms available, the one-way hash cannot be calculated backwards - meaning that the hash value cannot be decrypted to reveal the password in clear text again. This enhances security significantly as the password is only known to the user and an administrator accessing the database cannot make any sense out of the hash value. To verify the password each SAP system puts it into the hash value and compares this to the hash value that is stored in the database. As hash values are usually different in each backend system because each system uses a different algorithm, this should also explain to you that it makes no sense to synchronize passwords between systems - a request we often get. The hash value that resulted from the password XRT5zpd in SAP is totally different from the hash value the same password gets in a non-SAP system such as a directory server.
While performing user ID and password authentication, these do not get encrypted during transport. Thus we strongly recommend that you encrypt the communication path. Another option is to use digest authentication, where the password is encrypted using a so-called "digest." SAP allows for digest authentication for web applications with the J2EE Engine on SAP Web Application Server.
Instead of user ID and password, often stronger authentication mechanisms are requested. The most widespread is the X.509 certificate. The certificate serves as a user’s electronic passport and holds user information like the ID, a validity period, and a public key. The certificate can be issued electronically or can be stored on a smart card. The certificate cannot only be used to authenticate a user, but also to encrypt communication paths via SSL (Secure Sockets Layer that turns HTTP protocol into HTTP) or to digitally sign and encrypt data at rest or in transit. The X.509 certificate is accompanied by a set of keys. One is the private key that is only known to the certificate’s owner. The other is the public key that is published on the certificate. Both keys relate to each other by a mathematical algorithm, but neither key can be guessed from the other. The certificate is stored in the user’s browser while he/she accesses systems via the web. In the case of a server certificate this is usually stored in the server’s Personal Security Environment (PSE).
How do users get a certificate? Certificate enrollment can be a tedious process. You could buy them from a trust center. In some cases this might mean that you physically have to show up at a trust center office and show proof of your identification. Thus the trust center ensures that it is really you who wants to get a certificate. Of course those certificates come at a price. This should give you an idea about the security and reliability of certificates you can get by enrolling online. Usually those do not cost much, if anything at all, but the trust center does not verify your identity either. Happy impersonations!
You could set up a trust center for your company, which puts the burden on you to deal with another part of a trust center: the PKI. A trust center does not only have to deal with the issue of having users enrolled to get a certificate, issuing and publication of the certificates, but also generating the private and the public key pair. The public key is going to be published on the certificate and the private key is only made known to the certificate’s owner and stored securely. When certificates are issued on a smart card, then that is where the private key is stored. If they are issued in an electronic form, the private key has to be stored in a PSE.
How is the validity of a certificate verified? How do you know that a certificate didn’t get revoked? Various different things come into play here. Number one is that directory servers (which were already discussed above) often hold user master data, including the X.509 certificates. So the place to look up the certificate - including its attributes, validity period, public key, etc. - is a company directory in form of an LDAP server. In addition, trust centers or companies might publish CRLs (Certificate Revocation Lists), where revoked certificates are stored. This might be the case when the user lost his smart card or when he/she thinks someone accessed her laptop while her browser was open (an electronic certificate is stored in the browser) and performed some functionality. Instead of downloading those CRLs into your own systems every morning to get the newest updates on revoked certificates, you can use an Online Certificate Status Protocol (OCSP) responder instead. An OCSP responder is a software support that looks up the configured trust centers/PKIs, including CRLs for certificate validation either at regular time intervals or in real time while users authenticate or digitally sign data.
SAP allows for authentication (as well as digital signatures) with X.509 certificates with SAP EP, SAP Web Application Server 6.10, and the HTML GUI (ITS) and Pluggable Authentication Service (PAS). SAP has an own trust center where you can get certificates. See SAP Trust Center Services.
For stronger authentication mechanisms or smart card-based authentication, SAP allows for certified partners. See SAP Security Partners -> External Authentication.
What Single Sign-On mechanisms are available?
The main Single Sign-On mechanism with SAP systems is the logon ticket, a digitally-signed cookie that contains user ID, validity period, and a digital signature. You can use this with SAP EP or with the HTML GUI. Systems that can issue a logon ticket are SAP EP and SAP Web Application Server/Basis Release 4.6d and higher releases. Systems that can accept a logon ticket are release 4.0 and higher releases. If you want to use the logon ticket for access to non-SAP systems you can either adapt a ticket verification library, code a web filter, or provide a user mapping (account aggregation).
In the case of the WIN GUI or JAVA GUI you can use Secure Network Communication (SNC) in combination with a partner product. See SAP Security Partners -> SNC. For systems living in a Microsoft environment, only Microsoft offers the DLLs for free to re-use their Microsoft authentication.
Delegation of the Authentication Against an External Mechanism
What are options when you want to use an external authentication? This could for example be an LDAP bind (the user authenticates against the LDAP directory first) or Windows NTLM to name some. Delegation of the authentication for the HTML GUI is done via Internet Transaction Server (ITS) and PAS. In standard this allowed for configuration of the following options: LDAP, Windows User ID and password, Windows NTLM, HTTP header variables and X.509 certificates. Several partner products are certified for the ITS – PAS option. You can find them at SAP Security Partners -> External Authentication.
SAP EP allows delegation of the authentication against the user persistence store. Options are SAP ABAP stack 6.20 and higher, LDAP server and/or database. In addition we ship web filters for Windows authentication. For all other external authentication mechanisms, including partners, the SAP EP 6.0 SP4 (which is the SAP NetWeaver 04 Portal) shall be used. This offers so-called Java Authentication and Authorization Service (JAAS) login modules. JAAS is the standard that allows for delegation of the authentication against an external mechanism. We expect our partners to develop JAAS login modules for their products during the next time. Of course customers are free to develop their own login modules as well. If you are a potential partner who wants to get certified for this solution, or if you know a partner who might, please point him/her to information on our Integration and Certification Centers.
What is available with regard to identity federation? Before we delve into the details here, what problems does identity federation try to solve? If you imagine you're at a company that wants to give your business partner's employees access rights to your systems: Do you yourself want to maintain the business partner's users and roll-out and reset password, etc.? Most likely, not. How do you keep up to date if someone left your business partner's company? Most likely you do not. How could you? So in short: You do not wish to be bothered at all with user management for business partners’ employees. You want to federate identities with your business partners. You want to rely on the identities provided by the business partners.
One of the technologies related to identity federation is Security Assertion Markup Language (SAML), which allows for user authentication and his/her identity federation. SAML an XML dialect will become the upcoming glue to perform Single Sign-On - not only within one company, but for a trust of companies to allow for intra-company Single Sign-On. The main mechanism is assertion. In SAP language, this means that a user is allowed to logon on to an SAP system PRD to client 100 or to SAP EP. The SAML standard offers the options to make use of policies (date, time of logon, strength of authentication mechanism), which result in different assertions and thus different access rights. The following example shall illustrate this.
At Monday morning at 8:00 a.m. (your time zone), you log on from an internal IP address. Thus you receive an SAML ticket with an assertion that will allow you to access your company’s productive systems. At 11 p.m. on a Saturday night from an outside IP address, you receive an SAML assertion that only grants you access to your company’s internal web page. SAP currently supports SAML in the browser artifact scenario, where SAP accepts an SAML assertion that was externally pushed. This runs in the browser either via SAP EP or the SAP Web Application Server 6.30 or higher.
The next big portion of Access Management is the rights management and assignment of a user. In its simplest form, users get access to systems via group assignments, which are often stored in an LDAP server. The group represents a very simplistic access rights conglomerate. As this is very often not granular enough, there are two main access rights concepts that allow for more granularity.
One is the so-called role based access (RBAC), where navigational paths, system functionality (in SAP these are transactions and reports), as well as the information about the actual business data to be accessed (the actual authorizations on cost center ranges, personnel areas, financial accounts, etc.) is stored. Roles allow for a very fine-grained granularity accompanied by the high complexity, which administrators have to get along with.
The other form to give access rights is the Access Control Lists (ACLs). An object (could be business data, could be a folder) is assigned to an ACL. This ACL holds the users that are allowed to access the objects accompanied by their access rights that usually equal read, write, delete, copy, etc. ACLs are usually used where large amounts of unstructured data like files and folders have to be shared amongst groups of users. They are easy to maintain. You just have to assign or de-assign a user, but they do not offer a high amount of granularity.
SAP supports both role-based access and ACLs. Roles are used within SAP systems as well as on SAP EP to get access to structured data coming from business applications. ACLs are used on the portal to get access to unstructured content, anything that does not come from a business application.
Policy-based Authentication and Authorization
Concepts that will allow for even more granularity will evolve from policy-based authentication and authorization. This means that resulting from policies (date and time of logon, IP address, strength of authentication mechanism) users get not only authenticated to systems, but also get more or less access rights in the forms of roles. The standard that will support this is the one already discussed SAML. SAP will move forward to support more SAML features and functions than the pure authentication in the browser artifact scenario. However, SAP EP 6.0 currently already allows to make use of policy-based authentication in terms of strength of authentication mechanisms. For example, after a user has been successfully authenticated to SAP EP providing User ID and password you can enforce a stronger authentication (for example via an X.509 certificate) when a user accesses critical business functionality via a portal iView. The portal allows you to tie the required authentication mechanism per portal iViews and enforce a re-authentication with a stronger authentication mechanism.
How do users get their access rights changed? This could be done via workflow capabilities to be configured on SAP EP as discussed in the first part of this article.
Another option lies in the so-called indirect role assignment or position-based security. This is an option for customers that run SAP HR and have Organizational Management configured. Organizational management within SAP HR allows you to rebuild your organizational structure in the form of organizational units representing departments or groups and positions representing an employee’s position. The organizational management allows for assignment of attributes to the objects of the organizational structure. You have the option to assign roles to organizational units as well as to positions. Thus any employee assigned to a position will automatically (without the traditional roles assignment in the user administration transaction SU01) inherit the corresponding role assignment from his/her position and any organizational unit above him. This is an option to reduce role administration as employees changing positions and moving to different departments will automatically gain the corresponding access rights. Pre-requisite is that your administrators maintain the organizational structure well in advance prior to changes taking place. Please note that position-based role assignment is only supported within mySAP HR. It is not supported in SAP EP. You can use it in combination with a CUA, but you have to make certain configurations. The point that I am trying to get across here is that by going down this path you delimit/enforce certain configurations for the future.
To sum it up, SAP supports you with various options for user persistence stores, a directory integration, and workflow.
SAP offers various methods for authentication, Single Sign-On, and authorization management that allow you to leverage security mechanisms with appropriate strength. The implementation of Single Sign-On reduces your security administration significantly as you only have to roll-out one password instead of many. It increases security since end-users only have to memorize one password instead of many.