<<

. 66
( 87 .)



>>

the same infrastructure as the SAP applications and is responsible for SAP
application authentication, role administrations, and remote invocations.
Because it is built using the same infrastructure (called R/3 Basis), it is able
to implement security on behalf of the applications and is the key to SSO.
The infrastructure responsible for creating and delivering Web screens
based on the back-end function is ITS. ITS comprises of the WGate and the
AGate, the WGate being the interface to the Web server and the AGate being
the interface to the SAP back end. Of the two components the AGate does
most of the work and is responsible for session management, generating
HTML screens from R/3 screens, invoking functional modules from the
HTML, managing connections and sessions to the back end, and so on.
From a security perspective, ITS can make use of the internal security ser-
vices provided within mySAP.com Workplace or can delegate to an external
security manager using the Pluggable Authentication Service (PAS)”much
like WAS/WP can use its own authentication or use a TAI with a third-party
authentication server.
In order to use PAS, you need to establish a trust model between your
authentication server (for example, TAM) and mySAP.com. PAS is deployed
as a shared library used by the ITS gateway interface. ITS uses PAS to verify
the user authentication information generated by TAM. PAS queries TAM
and then sends the validated information to the SAP Workplace, which
returns a login ticket. This login ticket is then used as the SSO ticket when
accessing SAP modules. At a more detailed level the sequence is as follows:

1. User provides credentials, which are forwarded by the Web
server to WGate
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




394 Chapter 20


2. WGate sends the credentials to AGate
3. AGate forwards the credentials to TAM using PAS
4. TAM veri¬es credentials and replies to PAS
5. PAS passes the user information to the SAP Workplace
6. SAP user information is returned to PAS
7. PAS creates a login ticket and sends it back to the Web browser
8. WGate creates a cookie from the login ticket and sends it in the HTTP
response

Integrating TAM/WP with mySAP.com is done by de¬ning the mySAP
.com infrastructure within a TAM WebSEAL junction. Follow these steps
to con¬gure both TAM and SAP (for more details refer to the mySAP.com
and the TAM documentation):

1. Create a WebSEAL junction to the mySAP.com environment.
2. Add the line-META=CONTENT to webseald.conf.
3. Set script-filer to yes in webseald.conf.
4. Add entries for ¬ltering URLs to the JMT.
5. Add the line header=Accept-Encoding to the ¬lter request
headers section in webseald.conf.
6. Restart WebSEAL.
7. Copy sappdssocgi.exe from the mySAP.com installation into the
www/docs/cgi-bin directory in WebSEAL.
8. Create a secret trusted key named-sappdsso.key.
9. Install SAP Secure Network Communications (SNC) on your ITS
instance.
10. Stop the ITS Manager if it is running.
11. Copy the sappdssoauth shared library to the ITS programs
directory.
12. Copy sappdssoauth.srvc into the ITS services directory.
13. Copy your mySAP templates into the ITS templates directory.
14. Under TAM™s Policy Director directory, create an SAP directory
with subdirectories for etc, var, and bin.
15. Copy the secret key ¬le generated in step 8 to the etc directory.
16. Modify the login.html template copied in step 13; replace
WEBSEALSERVERNAME with the appropriate junction.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




Integrating Security and Identity Management Tools 395


SAP Enterprise Portal Integration
Because SAP has so many modules and offerings, it also develops and
sells portal solutions. In fact, in many environments SAP Portal is a di-
rect alternative to WP and there are many companies which deploy SAP
Portals as its portal even when the content delivered through the portal is
not exclusively sourced in SAP software. Still, SAP Portal is primarily used
in environments where SAP applications cover a majority of the business
functionality deployed in the organization. In environments where this is
true and yet portal functionality is still important, it is common to see two
portal infrastructures”WP as the overall portal and SAP Portal as a sub-
portal. This eliminates some of the pain involved with integrating many
SAP applications into WP. More on this topic in Chapter 23.
The SAP Enterprise Portal architecture is shown in Figure 20-4. Much like
WP Extend, Enable, and Experience, SAP Enterprise Portals are available
as three different offerings:
SAP Enterprise Information Portal (SEIP)”creating a uni¬ed
Web interface
SAP Enterprise Collaboration Portal (SECP)”including all
functionality in SEIP and adding personalization, collaboration,
categorization, and search capabilities
SAP Enterprise Uni¬cation Portal (SEUP)”including all
functionality in SECP with enhanced coordination capabilities and
virtual desktop capabilities




Figure 20-4 SAP Portal architecture.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




396 Chapter 20


As any portal, an SAP Enterprise Portal has its own implementation of
authentication, authorization, and administration of users. It also has its
own implementation of an SSO environment based on a login ticket. How-
ever, SAP Portals can externalize authentication and SSO to a third-party
product such as TAM and this is the preferred method when an SAP Por-
tal needs to be a part of a larger WP deployment. You can do this in one
of two ways. The ¬rst involves con¬guring the SAP Portal to use external
authentication by specifying the name of an HTTP header that contains the
authenticated user name and creating the appropriate WebSEAL junction.
The second is to use a WebSEAL Global Sign-On (GSO) junction, which
is con¬gured to pass the user name and password in the form of a Basic
Authentication header and con¬guring the SAP Portal to do normal LDAP
lookup. To implement the ¬rst option, follow these steps:

1. Ensure that both WebSEAL/WP and the SAP Portal share the same
LDAP user registry.
2. Set up a WebSEAL junction for the SAP Portal using the -c iv_user
option, allowing WebSEAL to pass the user id in the HTTP header.
3. Create a WebSEAL Junction Mapping Table (JMT).
4. Add IFRAME=REFRESHURL and PARAM=VALUE to webseald.conf
in the filter-url section.
5. Add TD=ONCLICK to the filter-events section in webseald
.conf.
6. Add scheme=hrnp to the filter-schemes section in webseald
.conf.
7. Add script-filter=yes and rewrite-absolute-with-
absolute=yes to the script-filtering section in
webseald.conf.
8. Log on to the SAP Portal as an administrator.
9. Select System Con¬guration ➪ User Management Con¬g ➪
Authentication Server.
10. Set User Authentication Type to External.
11. Set User Name Header to HTTP_IV_USER.
12. Click Apply.

To implement the second option, follow these steps:

1. Ensure that both WebSEAL/WP and the SAP Portal share the same
LDAP user registry.
2. Create a WebSEAL junction for the SAP Portal with the -v option.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




Integrating Security and Identity Management Tools 397


3. Follow steps 3“9 as described in option 1.
4. Set User Authentication Type to LDAP.
5. Enter the LDAP server information.
6. Click Apply.



Installing SiteMinder Support on WP
When using SiteMinder you have three options:
1. Using SiteMinder as a third-party authentication server
2. Using the SiteMinder Policy Server as an external security manager,
or
3. Both
Figure 20-5 shows the different Netegrity components that you may
choose to use and how they interact with WAS/WP. You may choose to
use Netegrity™s authentication server or another authentication server and
in either case can still use the Policy Server. The SiteMinder Policy Server
allows you to better de¬ne and control the security policy and, more specif-
ically, access control on your portal. At a WAS level, the Policy Server in-
teracts with three components (with portlets being managed by the Servlet
Agent Controller):
1. The EJB Agent Controller
2. The Servlet Agent Controller
3. The Web Agent Controller
When a protected resource is requested, the appropriate agent validates
the request with the SiteMinder Policy Server. As an example, when the




Figure 20-5 Using Netegrity SiteMinder with WP.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




398 Chapter 20


resource is an EJB or an invocation of an EJB method, the EJB Agent (which
is itself an EJB) communicates with the Policy Server using a set of Java
APIs and offers resource protection at the following granularity levels:
An entire package
Beans
Bean methods
Method signatures
The last granularity type”method signatures”allows you to de¬ne pro-
tection elements that are based on a combination of method and its param-
eters, that is, the signature a method may have rather than a unique bean
method.


Using SiteMinder as a Third-Party
Authentication Server
In order to install SiteMinder as a third-party authentication server you
need to install the SiteMinder TAI:
1. Install SiteMinder as a trusted authentication server:
a. Log in to the WAS Administration Console and click Security ➪
Authentication Mechanisms ➪ LTPA.
b. Click Trust Association.
c. Check the Trust Association Enabled check box.
d. Click Interceptors in the Additional Properties section.
e. Because SiteMinder is not one of the default authentication
servers, you will have to add it. Click New.
f. Enter the interceptor class name:
com.ibm.wps.sso.SiteMinderTrustAssociation Interceptor

g. Click Apply.
h. Click Custom Properties.
i. Enter custom properties as de¬ned in the SiteMinder installation
guide.
j. Click OK and restart the server.
2. Now that you have completed setting up SiteMinder as a trusted
reverse proxy, you can continue to Netegrity-speci¬c con¬guration:
a. Install the SiteMinder Java Agent API by adding the JAR ¬les in
<SITEMINDER_ROOT>/sdk/java to <WAS_ROOT>/lib and by
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




Integrating Security and Identity Management Tools 399


adding the appropriate JNI support library to the PATH variable
of the Java VM (for example, in Windows the support library is
called smjavaagentapi.dll). The primary Java class needed is
netegrity.siteminder.javaagent.AgentAPI, which can
be used to enforce access control by connecting to the Policy
Server. The Java Agent API insulates you from the implementation
details within the Policy Server and supports full session
management, automatic encryption key rollover, and real-time
policy updates. All Java-based SiteMinder agents make use of the
Java Agent API, and custom agents built using the Java Agent API
can participate with standard SiteMinder agents within an SSO
environment.
b. Set the validateSessions parameter to true within
siteminder.properties.
c. Follow the instructions in the Netegrity Policy Server
Management manual to de¬ne a Web Agent in the SiteMinder
Administration Console. This agent is required to establish a trust
association between WAS and SiteMinder and allows the TAI to

<<

. 66
( 87 .)



>>