Copyright © 2003 Americas’ SAP Users’ Group Session 811 Enterprise Buyer Professional Architecture and Application Security John Hodges, Daniel Belson.

Copyright © 2003 Americas’ SAP Users’ Group

Session 811Enterprise Buyer Professional Architecture and Application Security

John Hodges, Daniel Belson and Lynne Reiner

Wednesday, May 21, 2003 8:30 AM - 9:40 AM

Introduction

John Hodges – Senior Manager in our Security Services Practice (Los Angeles office, e-mail: [email protected]) Member of the ISACA, CISSP, and Certified Information Systems Auditor

(CISA). Has over ten years of relevant work experience in SAP security and integrity techniques associated with enterprise transformations.

Daniel Belson – Manager in our Security Services Practice (Los Angeles office, e-mail: [email protected]) CISSP, specializes in SAP security and application architecture. Has over

five years of relevant work experience with security & controls in ERP and e-business applications.

Lynne Reiner – Senior Consultant in our Security Services Practice (Chicago office, e-mail: [email protected]) CISSP, specializes in SAP security risk and controls. More than four years of

relevant work experience with implementing and auditing security and controls.

Agenda

Enterprise Buyer Professional (EBP) Overview(for Security Professionals)

EBP Architecture Security Implementation Scenarios Architecture Security

EBP Application Security Similarities and Differences to R/3 Security User Maintenance (including CUA)

EBP Lessons Learned (mix of topics)

Wrap-up (Q&A)

Strategic Topics

Tactical Topics

Overview

EBP Product History

1999 – 2001 Business to Business Procurement (BBP)

June 2000 – Announcement of SAP Commerce One Partnership

2001 & Beyond Enterprise Buyer Professional (EBP)

Versions 2.0, 3.0….versions 3.5 and 4.0 are now in development to be released

Overview – What is SRM?

SAP EBP, Enterprise Buyer Professional, is a new dimension product that is part of the mySAP Supplier Relationship Management (SRM) solution. This solution encompasses the ‘requisition to pay’ process with both buying and selling sides being integrated in real-time.

EBP empowers employees with self service procurement that enables direct and indirect procurement of goods and services.

Sourcing

BuyingExecution

• Approve or rejectrequirement coveragerequest

Manager

• Browse through online catalogs• Create shopping basket• Place order or save basket• Check status

Employee

• Receive purchase order• Confirm goods delivery

or service performed • Create invoice

Vendor

• Receive product • Check invoice

Employee

Overview – What is EBP?

With EBP, the complete cycle of procurement (both indirect and direct) business processes are automated and integrated with planning/execution systems.

Enterprise Buyer Professional (EBP) Overview(for Security Professionals)

EBP Architecture Security Implementation Scenarios Architecture Security

EBP Application Security Similarities and Differences to R/3 Security User Maintenance (including CUA)

EBP Lessons Learned (mix of topics)

Wrap-up (Q&A)

EBP Architecture - Components Front-end

SAPGUI for Windows (Project Team) Web Based (End-Users)

Web Service ITS (Internet Transaction Server) Understand in the future ITS will merge with Web Application Server (WAS)

Catalog Server Requisite’s Bugs Eye Search Engine & Catalog Emerge Search Engine & Catalog Aggregation

Business Connector/Exchange Infrastructure XML Enabler Understand in the future NetWeaver technology will provide middleware

Reporting Basic capability within EBP Long term solution is Business Intelligence (BW)

Security Note: We will discuss later how “user management” integrates into the architecture.

EBP Architecture – Example

EBP Architecture - Implementation Scenarios

EBP offers flexible deployment scenarios ranging from fully integrated into the supply chain to standalone scenarios

Depending on your available systems and business requirements EBP can be configured several different ways. Some of these options include:

Classic - connected SAP Backend for MM, FI and CO (procurement is initiated in EBP, but all official documents reside in SAP R/3)

Standalone - no SAP MM backend connected (all documents are created locally in EBP)

De-Coupled - mixture of classic & standalone scenarios : linked MM & FI backend (purchasing documents are created locally in EBP and in R/3)

Security Note: The implementation scenario can impact your security design and production support model (i.e., potentially role configuration dependencies across systems or two security production support teams).

EBP Architecture - Security Considerations

EBP is web enabled, thus additional security requirements beyond core application security should be considered

Security requirements to consider include:

User Population – are users accessing your EBP system from an external network or the Internet?

User Management – where will users of the EBP system be created (locally in R/3 and EBP, Central System – CUA, LDAP, etc…)?

Single Sign-On (SSO) – can your EBP system leverage an existing SSO implementation (SAP logon tickets, PKI, etc…)?

Data Encryption – what method of data encryption must your application comply with to meet company standards (SNC, SSL, etc…)?

Internet Transaction Server (ITS) Location – is your ITS installed behind a firewall or in the DMZ?

Enterprise Buyer Professional (EBP) Overview(for Security Professionals)

EBP Architecture Security Implementation Scenarios Architecture Security

EBP Application Security Similarities and Differences to R/3 Security User Maintenance (including CUA)

EBP Lessons Learned (mix of topics)

Wrap-up (Q&A)

Similarities with R/3 Security

Traditional security tools are still available… SU01 - User master record maintenance available through SAPGUI

for Windows User parameters, validity dates, logon data, etc… are still relevant

PFCG - Profile Generator still used to create roles Derived and composite activity groups available Transaction codes entered to generate profiles (USOBT_C is

limited in EBP) User menus maintained through Profile Generator

User to role assignment available through both SU01 or PFCG

Basis Authorization Objects (BC_) – basis objects available for project team and system access (i.e. S_TCODE, S_RFC, etc…)

Similarities with R/3 Security

SAP Pre-Configured Roles The EBP SAP delivered (both individual and composite) roles can be referred

to when designing security

SAP_EC_BBP_ADMINISTRATOR SAP_EC_BBP_EMPLOYEE SAP_EC_BBP_MANAGER SAP_EC_BBP_SECRETARY SAP_EC_BBP_VENDOR SAP_EC_BBP_PLANNER SAP_EC_BBP_PURCHASER SAP_EC_BBP_ACCOUNTANT SAP_EC_BBP_RECIPIENT SAP_EC_BBP_CONTENT_MANAGER SAP_EC_BBP_BIDDER

SAP delivered roles are a good place to start to determine transactions required, but are considered limited in terms of completeness

Security Note: In addition to the functional pre-configured roles, SAP also delivers a number of other roles including development, configuration and administration EBP roles.

Differences from R/3 SecurityConfiguration Differences include… New EBP specific authorization objects in Object Class BBP (limited number

of object available)

Basis authorization objects such as S_RFC (for RFC access) are required to perform EBP web transactions

Access restrictions in EBP have less focus on “organizational and functional” data elements and more focus on Business Workflow and Organization Plan

Transactions available for a user still determined through traditional roles assigned

User access determined from location on the Organizational Hierarchy and inheritance of Attributes

Users can inherit attributes based on; 1) the node they are assigned in the Organizational Structure, 2) assigned roles, and 3) user defined attributes

Security Note: Some new EBP transactions replace similar R/3 transactions (i.e. BBPBWSP – EBP Inbox instead of BSWP - Inbox).

Differences from R/3 Security

There are two main types of Attributes Organizational Structure Attributes: Assigned to an organizational

unit via the hierarchy. They define access for users assigned to the unit. They can only be maintained by authorized administrators in the organizational structure.

User Attributes: Assigned to a user ID via the organizational hierarchy, role, or user master record (i.e., approval limits or authorization level of the approver)

Users can change their default User Attributes if granted authorization within their role to transaction code BBPATTRMAINT - Change Attributes.

Security Note: Special consideration should be taken to determine at what level Attributes are assigned (user, role, or organizational hierarchy) and if should allow changes to User Attributes.

Example EBP Screen – Org Hierarchy

Example of how an user inherits an organizational attribute:

1. Organizational unit is assigned an attribute

2. Position assigned to an organizational unit

3. User assigned to a position

Security Note: Key security attribute BBP_WFL_SECURITY - Authorization Level of Approver

Differences from R/3 Security

Navigation Differences Variations in the login process

End Users login via a web front end vs. SAPGUI

User Menus for web users are mandatory (see picture) Same basic structure is recommended

Certain transactions are only available through the web and can not be started via the command line (e.g., BBPPU99 – Shop)

Command line can be used via the web; however, most users will navigate via the menu structure

Standard EBP Monitor

Active Roles assigned to a user

Differences From R/3 Security

Administration Differences Troubleshooting is different

Traditional security production support tools not effective for web users (i.e., user error buffer - SU53 and user authorization trace – ST01)

Instead review system logs in the SAPGUI (via Transaction SM21)

Development instances required to be less restricted for project teams In EBP 3.0 manual configuration is required in all clients - many

things do not transport because they are client dependent (e.g., ALE Models, Logical Systems, etc… )

Continually maturing module leads to a large number of Hot Packs and version changes Need to make sure OSS notes in Hot Packs are reviewed for security

impact

EBP User Creation Process

Users can be broken into two groups for EBP1. Project Team Users that perform configuration, development or

BASIS tasks can be maintained through traditional SAP roles

2. Web Users that are typically associated with a position in the organizational hierarchy and are controlled by Workflow security

These groups of users have different security maintenance requirements Project Team Users can be maintained via SAPGUI (traditional method via

transaction SU01) Web Users can be maintained either directly through the web

(BBPUSERMAINT – Manage User Data) or through traditional method via SU01. If created via SU01, then an additional step must be executed to convert the user to a Web User (USERS_GEN – User Generation)

Security Note: If your users and organizational hierarchy exist in both your backend R/3 and EBP systems, maintenance can occur in the R/3 system and be replicated to EBP (then only attribute maintenance required in EBP).

Example EBP Screen - User Creation Process

Security Note 2: Web Users created via SU01 can later be assigned to the Org Hierarchy through transaction USERS_GEN – Generate Users (mass user creation also available).

Security Note 1: Web Users can be created directly via the Web through transaction BBPUSERSMAINT – Manage User Data.

CUA does work with EBP, but implementation is different than with other components (e.g., R/3 or BW)

SAP provides OSS Note 0000402592  - “EBP in the environment of a Central User Administration” that describes how user creation in EBP can co-exist with a central CUA system located in another application. 

This note describes how users can be created in two different SAP applications that are integrated in CUA, which could cause synchronization problems - Not recommended

The CUA model is highly dependent upon the system landscape

EBP User Creation Process - CUA

Central User Administrator (CUA) provides flexibility for maintaining user master record information, from a central location, to multiple SAP applications.

Considerations when deploying CUA in a EBP landscape Is there a separate system available to locate a central CUA

instance? Is an organizational hierarchy available in a connected R/3

application to leverage for EBP? What is production supports capacity to manage users and the

organizational hierarchy?

Depending on answers to the above, some options include: Separate CUA server managing users with either an organizational

hierarchy located in a R/3 system. replicating to EBP or assigning users to the organizational hierarchy locally in EBP through USERS_GEN

Separate CUA server managing users for all applications except EBP

EBP User Creation Process - CUA

Security Note: This is a complicated topic with lots of considerations. Recommend playing out several scenarios before finalizing a decision.

Enterprise Buyer Professional (EBP) Overview(for Security Professionals)

EBP Architecture Security Implementation Scenarios Architecture Security

EBP Application Security Similarities and Differences to R/3 Security User Maintenance (including CUA)

EBP Lessons Learned (mix of topics)

Wrap-up (Q&A)

EBP Lessons Learned – Mix of Topics

There are several EBP options available for workflow messaging These workflow options include: 1) link to EBP logon screen, 2) link

to EBP workflow item and 3) remote reply Each of the above options have potential security implications:

Potential link to EBP sent unencrypted over public network Remote reply workflow relies on authentication driven off of e-

mail address and user ID (potential for spoofing) Users that only interact with EBP via remote reply will never

show as having logged on SAP

Security for Goods Receipt functionality in EBP is limited to two options: 1) receive own goods or 2) receive all goods No ability in EBP to receive goods by organizational attribute

configuration

The lessons learned outlined below are primarily driven from EBP 3.0 implementation experiences.

EBP Lessons Learned – Mix of Topics

Roles assigned to users via the web through transaction BBPUSERMAINT must be in ‘Z’ or ‘Y’ name space.  There is a system parameter setting to show all roles, but this shows all SAP roles as well

There are only two standard reports are available in EBP and neither of them include any auth checking (i.e.,BBP_BW_SC4 – Shopping Carts per Cost Center and BBP_BW_SC3 – Shopping Carts per Product) SAP recommends BW for long term EBP reporting solution, but if

standard reports are to remain in use, custom security checking should be considered

Mass User Compare in EBP had some issues which caused users to lose role assignment 

EBP Lessons Learned – Mix of Topics

Potential error codes for web users when logging on: You are not authorized to logon to the target system (error code 1).

--> This is a incorrect password error You are not authorized to logon to the target system (error code 2).

--> This is a locked user error

When considering SSO requirements that include EBP and other applications, evaluate Enterprise wide solutions that leverage 3rd party solutions (i.e., Netegrity, Oblix, etc…)

Enterprise Buyer Professional (EBP) Overview(for Security Professionals)

EBP Architecture Security Implementation Scenarios Architecture Security

EBP Application Security Similarities and Differences to R/3 Security User Maintenance (including CUA)

EBP Lessons Learned

Wrap-up (Q&A)

Copyright © 2003 Americas’ SAP Users’ Group

Thank you for attending!

Please remember to complete and return your evaluation form following this session.

Session Code: 811