Date post: | 15-Jan-2016 |
Category: |
Documents |
View: | 217 times |
Download: | 0 times |
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