What is Identity Management? - Part 2

[Former Member]

What is Identity Management? – Part 2

Intro

In the What is Identity Management? - Part 1 we had discussed features and functions of the user management lifecycle, how user master data is provisioned, how a central repository helps you etc.

This Weblog post will focus on the Access Management piece of Identity Management. How do users get authenticated and gain access rights to back-end systems?

Term Clarifications

First let’s get some terms clear that are often mixed and thus misunderstood. Authentication means: What mechanism is provided by a user to get authenticated or to get his 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 back-end 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 overruling your systems own user authentication, if you will. 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.

Authentication Mechanisms

What authentication mechanisms are available? In its simplest form a user provides 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 etc. SAP supports basic and form-based authentication for web applications with the J2EE Engine on the 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 ID 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 back-end system, because each system uses a different algorithm this should also explain to you that it makes no sense in synchronizing 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 like a Directory Server for example.

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 the 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 for example 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 https) 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 accesses systems via the web. In the case of a server certificate this is usually stored in the server’s PSE (Personal Security Environment).

How do user’s get a certificate? Certificate enrolment can be a burdensome process. You could buy them from a so-called Trust Center. In some cases this might mean that you physically have to show up at one of the Trust Center’s offices and show proof of your identification. Thus the Trust Center ensures that it’s 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 impersonation!

You could set up a company’s own Trust Center, which puts the burden on you to deal with another part of a Trust Center: the PKI (Public Key Infrastructure). A Trust Center does not only have to deal with the issue of having user’s enrolled to get a certificate, issuing and publication of the certificates, but also to generate 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 (Personal Security Environment).

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 in part 1) 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 so-called Certificate Revocation Lists CRLs, where revoked certificates are stored. This might be the case when the user lost his smart card or when she thinks someone accessed her laptop, while her browser was open (an electronic certificate is stored in the browser) and performed functionality. Instead of downloading those CRLs into your own systems every morning to get the newest updates on revoked certificates you can use an OCSP (Online Certificate Status Protocol) responder instead. An OCSP responder is a software support that looks up the configured Trust Centers/PKIs including CRLs for certificate validation either at a regular time interval 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 the Enterprise Portal, the Web Application Server 6.10 and the HTML GUI (ITS) and PAS (Pluggable Authentication Service. SAP has an own Trust Center, where you can get certificates. SAP Trust Center Service

For stronger authentication mechanisms or smart-card based authentication SAP allows for certified partners. SAP Securitypartner List

Single Sign-On options

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 the Enterprise Portal or with the HTML GUI. Systems that can issue a logon ticket are the Enterprise Portal and an 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 (so-called account aggregation).

In the case of the WIN GUI or JAVA GUI you can use SNC (Secure Network Communication) in combination with a partner product. SAP Securitypartner List - 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 a few. Delegation of the Authentication for the HTML GUI is done via ITS (Internet Transaction Server) and PAS (Pluggable Authentication Service). 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 certified for the ITS – PAS option. You can find them here: SAP Securitypartner List - External Authentication.

The Enterprise Portal allows in standard to delegate the authentication against the user persistence store. Options were 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 mechanims including partners the SAP Portal 6.0 sp4 (which is the Netweaver 04 Portal) shall be used. This offers so-called JAAS (Java Authentication and Authorization Service) 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 to this link giving access to our Integration and Certification Centers: SAP Integration and Certification Center

Identity Federation

What is available with regards to Identity Federation? Before we delve into the details here, what problems does Identity Federation try to solve? If you imagine you are a company and want to give your business partners’ employees access rights to your systems: Do you yourself want to maintain the business partners’ users and roll-out and reset passwords etc? The answer is: No you don’t want to add all this security administration. 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 SAML (Security Assertion Markup Language) that 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 the so-called assertion. In SAP language this means that a user is allowed to logon on to an SAP system PRD to client 100 or to the Enterprise Portal. 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 am your time zone you log on from an internal IP address. Thus your receive a SAML ticket with an assertion that’ll allow you to access your company’s productive systems. At 11 pm on a Saturday night from an outside IP address you receive a SAML assertion that only grants you access to your company’s internal web page. SAP currently supports SAML in the so-called browser artifact scenario, where SAP accepts a SAML assertion that was externally pushed. This runs in the browser either via the Enterprise Portal or the SAP Web Application Server 6.30 or higher.

Authorization Management

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 so-called 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. Access Control Lists 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 Access Control Lists. Roles are used within SAP systems as well as on the Enterprise Portal to get access to structured data coming from business applications. Access Control Lists 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 already discussed SAML. SAP will move forward to support more SAML features and functions than the pure authentication in the browser artifact scenario. However, the Enterprise Portal 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 the Enterprise Portal 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 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 the Enterpries Portal as discussed in What is Identity Management? - Part 1.

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 configured the Organizational Management. 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 though that your administrators maintain the organizational structure well in advance prior to changes taking place.

Summary

SAP offers various methods for authentication, Single Sign-On and Authorization management that allow 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. And it increases security as end-users do only have to memorize one password instead of many.