How-to Guide

SAP NetWeaver 04

How To
Developing
User Management
Engine 4.0
Version 1.00 Juni 2004

Applicable Releases:
SAP NetWeaver 04

 Copyright 2004 SAP AG. All rights reserved.

No part of this publication may be reproduced or
transmitted in any form or for any purpose without
the express permission of SAP AG. The
information contained herein may be changed
without prior notice.
Some software products marketed by SAP AG
and its distributors contain proprietary software
components of other software vendors.
Microsoft, Windows, Outlook,P Pand PowerPointP
Pare registered trademarks of Microsoft
Corporation.
IBM, DB2, DB2 Universal Database, OS/2,
Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400,
OS/390, OS/400, iSeries, pSeries, xSeries,
zSeries, z/OS, AFP, Intelligent Miner, WebSphere,
Netfinity, Tivoli, and Informix are trademarks or
registered trademarks of IBM Corporation in the
United States and/or other countries.
Oracle is a registered trademark of Oracle
Corporation.
UNIX, X/Open, OSF/1, and Motif are registered
trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame,
WinFrame, VideoFrame, and MultiWinP Pare
trademarks or registered trademarks of Citrix
Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or
registered trademarks of W3CPP, World Wide
Web Consortium, Massachusetts Institute of
Technology.
Java is a registered trademark of Sun
Microsystems, Inc.
JavaScript is a registered trademark of Sun
Microsystems, Inc., used under license for
technology invented and implemented by
Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp,
SAP NetWeaver, and other SAP products and
services mentioned herein as well as their
respective logos are trademarks or registered
trademarks of SAP AG in Germany and in several
other countries all over the world. All other product
and service names mentioned are the trademarks
of their respective companies. Data

c ontained in this document serves informational

purposes only. National product specifications
may vary.
These materials are subject to change without
notice. These materials are provided by SAP AG
and its affiliated companies ("SAP Group") for
informational purposes
only, without representation or warranty of any
kind, and SAP Group shall not be liable for errors
or omissions with respect to the materials. The
only warranties for SAP Group products and
services are those that are set forth in the express
warranty statements accompanying such products
and services, if any. Nothing herein should be
construed as constituting an additional warranty.
These materials are provided as is without a
warranty of any kind, either express or implied,
including but not limited to, the implied warranties
of merchantability, fitness for a particular purpose,
or non-infringement.
SAP shall not be liable for damages of any kind
including without limitation direct, special, indirect,
or consequential damages that may result from
the use of these materials.
SAP does not warrant the accuracy or
completeness of the information, text, graphics,
links or other items contained within these
materials. SAP has no control over the information
that you may access through the use of hot links
contained in these materials and does not endorse
your use of third party web pages nor provide any
warranty whatsoever relating to third party web
pages.
SAP NetWeaver How-to Guides are intended to
simplify the product implementation. While specific
product features and procedures typically are
explained in a practical business context, it is not
implied that those features and procedures are the
only approach in solving a specific business
problem using SAP NetWeaver. Should you wish
to receive additional information, clarification or
support, please refer to SAP Consulting.
Any software coding and/or code lines / strings
(Code) included in this documentation are only
examples and are not intended to be used in a
productive system environment. The Code is only
intended better explain and visualize the syntax
and phrasing rules of certain coding. SAP does
not warrant the correctness and completeness of
the Code given herein, and SAP shall not be liable
for errors or damages caused by the usage of the
Code, except if such damages were caused by
SAP intentionally or grossly negligent.

1 Developer Tutorial User Management Engine 4.0

1.1

Summary

EP 6.0 uses the SAP User Management Engine (UME) 4.0 to enable integration of the portal
with a customer's existing LDAP or user management solution. The UME is used by the SAP
Netweaver platform.
The scope of this document is to a Developer Guide for the User Management Engine (UME)
that is provided by the Web Application Java Server for Java applications and Enterprise
Portal Components.
From the application point-of-view, the UME provides three main functions:

1.2

Authentication: Which user is logged in?

Authorization: What is this user allowed to do?
Profile: What is the user's name, address, ...
Overview

UME user data is stored in one or more repositories. Each type of repository has its own
persistence adapter. The application-programming interface (API) is a layer on top of the
persistence manager. Please refer to the online help for the UME for configuration
information.

1.3

User Authentication and Single Sign-On

There are several mechanisms available for authenticating users on the SAP NetWeaver
platform. In addition, if you have many systems in your system landscape, then a Single Sign-

On environment is also desirable to reduce the number of passwords that users have to
remember.
The SAP Web Application Server (SAP Web AS ) is the underlying technology for
authenticating users with SAP NetWeaver. See the tables below for an overview of the
mechanisms available for each SAP Web Application Server personality and whether the
mechanism is used directly for user authentication or for Single Sign-On.
Mechanism

User
Authentication

Single
Sign-On

ABAP

Java

User ID and password

Secure Network Communications (SNC)

SAP logon tickets

SSL and X.509 client certificates

Pluggable Authentication Services (PAS)

Security Assertion Markup Language (SAML)

Java Authentication and Authorization Service
(JAAS)

x
x

For more information about how these mechanisms work and how to configure them on the
SAP Web AS , see http.//help.sap.com
1.4

User Management and Security Files

Files used by user management and security components:

sapum.properties
Contains configuration parameters for user management and security
<SAP_J2EE_Engine_installation_directory>\ume
authschemes.xml
Contains definition of authentication schemes available in the portal.
<SAP_J2EE_Engine_installation_directory>\ume
ticketKeyStore
File store for portal key pair. Can include additional certificates of entities that
are trusted by the portal.
<SAP_J2EE_Engine_installation_directory>\ume
verify.der
Certificate of the Portal Server in DER format. These files are not available
on the file system.
verify.pse
Certificate of the Portal Server in Secude PSE format. Includes any
certificates that were imported into ticketKeyStore.
You can download them using the Keystore Administration tool.

2 UME 4.0 - Authentication

2.1

Summary

You can use different types of authentication on the SAP Enterprise Portal. This enables you
to choose the required type of security authentication mechanisms for your applications.
The logon stacks enable you to choose different combinations of authentication types for
each application you create, and for each of the components on the server with applied
security restrictions.
2.2

Interface IAuthentication

A prerequisite for any access control and business logic is that a user is logged on. We
provide a simple API to check whether a user is logged in, to enforce that a user is logged in
and to get the logged in user (object):

public interface IAuthentication {

//Returns the logged on user or null, if no user is logged on.
public IUser getLoggedInUser(
HttpServletRequest req,
HttpServletResponse resp);
/*
* Checks whether a user is currently logged on
* and returns his/her user id. If the user is
* not yet logged on, a respective logon page is
* written as ServletResponse. In that case (for
* example, null is returned), the calling servlet can
* simply end its doGet or doPost method with return.
*
*/
public IUser forceLoggedInUser(
HttpServletRequest req,
HttpServletResponse resp)
throws UserManagementException;
//Logs the user out
public void logout(
HttpServletRequest req,
HttpServletResponse resp);

Example:
With the following lines of code at the beginning of a servlet you can enforce that a user is
logged on:

package com.sap.security.api;
IUser user =
UMFactory.getAuthenticator().forceLoggedInUser(
req,
resp);
if (user == null)
return;

Subsequently, the returned user object can be used for access control and to query the users
profile.
Note:
As forceLoggedInUser() changes the response if the user isn't yet logged on (see next
chapter for details), make sure that you

do not write to the response before calling forceLoggedInUser()

do not write to the response when forceLoggedInUser() returns null (i.e. end the
servlet)

Thus, you should not use forceLoggedInUser within a servlet, but in the controller servlet (see
for example, struts for details). Then, use getLoggedInUser() within your application.
2.3

Session Handling

If applications use J2EE's session management to store confidential and user relevant
information, we have to make sure that this information is invalidated if the logged on user
changes. J2EE's session management is explicitly local to an application / servlet context.
While we do not plan to develop a global central session management, we still have to
implement the functionality for the logged on user.
From the Servlet Specification: HttpSession objects must be scoped at the application /
servlet context level. The underlying mechanism, such as the cookie used to establish the
session, can be shared between contexts, but the object exposed, and more importantly the
attributes in that object, must not be shared between contexts.
Scenario:
1. User A logs on and accesses some data that is temporarily stored in the session
context of the servlet.
2. User A logs off
3. User B logs on.
4. Now, all information related to user A must be invalidated. (Otherwise, user B might
be able to get access to some of users information
This is realized with the following procedure in getLoggedInUser() /
forceLoggedInUser():
Whenever a new user logs on, we store a reference to the logged on user in the session (if
necessary, a new session is created).
If the session already contains a reference to a different user (this includes the case that the
session contains a user reference but there's currently no user logged on), the session is
invalidated.
On log off, the SSO cookie is removed and the session is invalidated.
Thus, it is essential that the applications use getLoggedInUser() at every request.
Note:
By caching the necessary information to verify whether the logged on user has changed, UM
will optimize the performance of getLoggedInUser().
2.4

How SSO works

Although this is transparent for the applications and might change in the future, here's a brief
description of how authentication and SSO work:

After a user successfully logs on, an encrypted cookie is sent to the user.
In subsequent requests, this cookie can be used for SSO. The method getUser()
verifies that cookie and retrieves the user information, if available.
The same is true for forceLoggedInUser(), if a cookie exists.

If forceLoggedInUser() is called and the user is currently not logged on (for example,
he does not have the cookie), he is redirected to the logon page (or the HTML-code
for the log on page is sent directly). In that step, the current URL (for example, the
URL of the servlet or JSP that has called forceLoggedInUser()) is passed to the logon
page. After a successful logon, the user is automatically redirected back to the current
servlet.

3 UME 4.0 Iuser, IGroup, IRole

3.1

User Management Factory

All non Portal Applications access all the functionality of UME through the class
com.sap.security.api.UMFactory.
For EP access via IUser me = request.getUser(); See obtaining a user object below
//Get an 'IUserFactory'-object to instantiate user-objects.
IUserFactory userFactory= UMFactory.getUserFactory();

3.2

Interface IUser

The central point of the Usermanagement is the user object exposed to the application by
implementing one of the following interfaces:
Interface IUser
This interface provides read-access to all available information:
the Company the user belongs to
the profile like name, address
the authorization information (is the user allowed to do something?)
Interface IUserMaint
This interfaces extends the IUser interface and adds the possibility to modify the user
data.
Note
This separation was done for multiple purposes:
Most of the time, the applications only need read access. By using the special readonly interface, we improve the performance of the application significantly.
The design of the Business Service Framework defines the user information as
central information maintained centrally. Thus, changing the data should only occur in
very special situation.
3.3

Obtaining a User Object

To get the currently logged on user object, use the IAuthentication interface as described in
the next chapter. To get any user object either based on a unique key or by doing a search,
use the methods available in the IUserFactory.
//get
IUser
//get
IUser
//get
IUser

user by portalrequest
me= request.getUser();
any user
getUser(String uid);
logged on user
user= userFactory.getUserByLogonID(username);

For details, please refer to the Javadoc.

3.4

Service User

A service user is a programmatically created user that is authenticated and whose attributes
contain a valid ticket. Its purpose is basically to impersonate an identity with certain privileges.
Service user don't log on interactively. The ticket that's contained in the attributes is usually
used to log on to a remote portal/SAP System/whatever from within a batch job or whatever
(in situations where no interactive logon has taken place).
For a service user it is possible to define usermapping, assign a role and to assign free
attributes.
3.4.1 ServiceUserFactory
The serviceUserFactory is accessible via the UME API in
UMFactory().getServiceUserFactory()
The ServiceUserFactory provides following methods:
public com.sap.security.api.IUser getServiceUser(
String uniqueName)
throws UMException
In order to get a service user the above message has to be called. The serviceUserFactory
verifies that this user is a service user. Service users are defined as regular users, but have
their own namespace:
private static final String SERVICEUSER_NAMESPACE=
"$serviceUser$";
After verifying the service user this method returns an IUser object with a ticket attached to a
transient attribute. The user
user.setTransientAttribute(
ILoginConstants.SSOTICKET_USER_ATTRIBUTE,
t);
public IUserMaint newServiceUser(String uniqueName)
throws UMException;
public void deleteUser(String uniqueID) throws UMException;
boolean isServiceUser(String uniqueName)

allows to verify if a user with a given uniqueName is a service user.

3.4.2 Configuration and data store
Service Users reside only in the database. This can be achieved by settings in the
configuration file.
The settings only allow service users to be searched/retrieved/created in the database.
Service users are stored as users only who do not have a user account. Storing only user
profiles (object type IUser) has following advantage:
no interactive logon possible: authentication will first check in the store of accounts and will
not find a user account for a service user no special coding necessary for authentication
process
Service users can be delivered initially in the database when the UME tables are created.
After creating the UME tables, following users for Knowledge Management are automatically
inserted:
"index_service" ,
"subscription_service",
"ice_service",
"collaboration_service",
"timebasedpublish_service",

"notificator_service",
"cmadmin_service",
"action_inbox_service"
3.4.3 Authentication of service users
Service users which are returned via the factory only have a ticket attached in the transient
attributes. Since the service users are only contained in the database they
3.4.4 Security of service users
Service users own certain privileges that are needed to perform a special task. E.g. we might
need a special service user that has all necessary permissions to perform every possible task
on an ACL (delete, modify, etc.). Obviously, the API to create service users must be
protected. Therefore, we plan to add a permission check to the create() method of the service
user factory. See the below code sample.

IUser createServiceUser(String uid) {

SecurityManager secman= UMFactory.getSecurityManager();
if (secman != null) {
ProtectedCallPermission p=
new ProtectedCallPermission(
createServiceUser,
uid);
secman.checkPermission();
}
}

As one can see, the call name acts as target and the user name as action. Using this
granularity, you can specify in a detailed manner which code can instantiate which service
users. Possible privileges could be
codeBase ${portal.home}\WEB-INF\portal\&#8230;\private\lib\km.jar {
grant ProtectedCallPermission createServiceUser
IndexService,QueueService;
}
3.5

Accessing the Logon ID of a user

In EP 5.0 you could simply call getUid() to obtain the logon ID. This method is deprecated
in EP6 due to the fact that a user can be associated with multiple logon accounts.
getUniqueId() as a replacement for getUid(), but this returns a value that must be
parsed to get the logon ID. You can access the actual logon ID by iterating through the
IUserAccounts array obtained by calling getUserAccounts(). The logon ID is retrieved
using the new call getLogonUid(). Often times you can simply pick the first element in the
array:

String logonID= user.getUid();

IUserAccount accounts[]= null;
try {
accounts= user.getUserAccounts();
} catch (UMException e) {
response
.write(
("<br>Error getting accounts: "
+ e.getLocalizedMessage());
}
if (accounts != null) {

response.write(
"<br>Number of Login Accounts: " + accounts.length);
for (int i= 0; i < accounts.length; i++) {
response.write(
"<br>** Login ID #"
+ i
+ ": LogonUID="
+ accounts[i].getLogonUid()
+ ", AssignedUID="
+ accounts[i].getAssignedUserID());
response.write(
"<br>Last Login: "
+ accounts[i]
.getLastSuccessfulLogonDate()
.toString());
response.write(
"<br># Logins: "
+ accounts[i].getSuccessfulLogonCounts());
}
}

3.6

Obtaining Role information

EP6 contains a enhanced role structure. The role structure in EP5 was fairly simple and each
role name was unique. In EP6, roles can now be nested in folders which was not possible in
EP5. This new structure facilitates new mechanisms for delegated administration and other
scenarios. As a result, all roles now have a unique identifier which allows the UME to prevent
name clashes (e.g. roles having the same name). Most of the role APIs require the unique
role ID as a handle or key to obtain the role information.
List of roles for a specific user
A list of roles can be obtained by calling getRoles() on the IUser object. This returns an
iterator that allows you to stroll through the roles the user has. The iterator contains the
unique Ids of the roles associated with the user. In order to get the actual information about a
specific role you need to use the Role Factory to obtain an instance of that role. The unique
ID is passed to the role factory's getRole() method.

response.write("<br>**** ROLE INFORMATION:");

if (rit.hasNext()) {
IRoleFactory rfact = UMFactory.getRoleFactory();
while (rit.hasNext()) {
String roleName = (String) rit.next();
IRole role = null;
try {
role = rfact.getRole(roleName);
response.write("<br>Role:" + roleName
+ "<br>Display Name:"
+ role.getDisplayName()
+ "<br>ID: " + role.getUniqueID()
+ "<br>Uniquename: " + role.getUniqueName()
+ "<br>Description: " + role.getDescription());
} catch (UMException e) {
response.write("error: " + e.getLocalizedMessage());
}
}
}

3.7

Search for Users, Roles and Groups

There is the possibility to search for users with arbitrary attributes. To do that, you obtain
IUserSearchFilter with the following method:
public IUserSearchFilter getUserSearchFilter() throws UMException
Once the IUserSearchFilter contains all search attributes, you can search the respective
users with:
public ISearchResult searchUsers (IUserSearchFilter filter)
Searching for a role involves a few steps:
1. Build a search filter (IRoleSearchFilter) to look for the role,
2. Execute the search by calling searchRoles() on the Role Factory
3. Iterate through the search result list (ISearchResult)
The following example attempts to obtain a single role. It throws an exception if the role is not
found, or the name is not unique (e.g. search returns more than one role).

IRole getSingleRole(String searchStr, boolean fuzzy) throws

UMException {
IRoleFactory rfact = UMFactory.getRoleFactory();
IRoleSearchFilter isf = rfact.getRoleSearchFilter();
if (fuzzy) {
isf.setDisplayName("*" + searchStr + "*",
ISearchAttribute.LIKE_OPERATOR,
false);
} else {
isf.setDisplayName(searchStr ,
ISearchAttribute.EQUALS_OPERATOR,false);
}
ISearchResult sr = rfact.searchRoles(isf);
if (sr.size() == 0)
throw new UMException("Role: " + searchStr + " not found");
if (sr.size() == 1)
return rfact.getRole((String) sr.next());
else
throw new UMException(
"Role: "
+ searchStr
+ " not unique (found "
+ sr.size()
+ " matches)");
}

3.7.1 Determining if a user is a member of a Role or Group

You can determine whether or not a user is a member of a particular role or group by using
the method calls isMemberOfRole() or isMemberOfGroup(). You must pass the unique ID of
the role or group to this call, so you probably have to look it up before calling either method.

IRole superRole= null;

try {
superRole= getSingleRole("super_admin", false);

10

} catch (UMException e) {
response.write(
"Error getting role: " + e.getLocalizedMessage());
}
if (user.isMemberOfRole(superRole.getUniqueID(), true))
response.write(" IS a super admin");
else
response.write(" IS NOT a super admin");

Working with Groups

The Group API is very similar to the Role API and uses a similar set of methods. Refer to the
information above for accessing, searching for, and determining membership of Groups. See
the UserSamples.java for furtehr details.

11

4 User Mapping
4.1

Summary

User mapping is a feature that has been introduced first to SAP products with EP 5.0. It is a
facility to maintain logon data for users for 3 rd party systems. What I call "logon data"; can be
simply user id and password, but also additional data like NT-Domain, language. In EP 5.0,
user mapping is available as both a personalization feature available for every end user and
as an admin feature that allows administrators to map users, groups or roles to specific
accounts. In a productive environment, the user mapping functionality contains a html UI that
allows to maintain the data. In order the portal environment, the UI calls the system landscape
service to get a complete list of all the systems that user mapping should be possible for (thus
every system that user mapping is desired for needs a certain flag in the system landscape).
4.2

Programming UserMapping with Enterprise Portal 6.0

For accesing User Mapping data, the UME offers two Interfaces:
IUserMappingService and IUserMappingData.
IUserMappingService is available via ServiceReference= " com.sap.portal.usermapping "
The following Code Sample explains the use of the usermapping API:
import
import
import
import
import
import
import
import
import

java.util.HashMap; import java.util.Map;

com.sap.security.api.IUser;
com.sap.security.api.umap.IUserMappingData;
com.sap.security.api.umap.NoLogonDataAvailableException;
com.sapportals.portal.prt.component.AbstractPortalComponent;
com.sapportals.portal.prt.component.IPortalComponentRequest;
com.sapportals.portal.prt.component.IPortalComponentResponse;
com.sapportals.portal.prt.runtime.PortalRuntime;
com.sapportals.portal.prt.service.usermapping.IUserMappingService;

public class UserMapping extends AbstractPortalComponent

{
public void doContent(IPortalComponentRequest request,
IPortalComponentResponse response)
{
// obtain system
String systemalias = "system";
// get user from request
IUser iuser = request.getUser ();
// get usermapping service
IUserMappingService iums = (IUserMappingService)
PortalRuntime.getRuntimeResources().getService(IUserMappingService.KEY);
IUserMappingData iumd = iums.getMappingData (systemalias, iuser);
Map map = new HashMap ();
try {
iumd.enrich (map);
}
catch (NoLogonDataAvailableException nldae)
{
// Error handling
}
// In m is all data

12

String userid = (String)map.get( "user" );

String pwd = (String)map.get ("mappedpassword");
response.write("hallo" + userid);
response.write(" "
+ pwd);
}
}

13

5 UME 4.0 - Access Control List (ACL)

5.1

Summary

The portal infrastructure allows many users to perform an operation on a resource, for
example create, modify and delete a portal object. Therefore it is necessary to provide a
security concept, which allows the application to check that the user has the permission to
perform an action. The concept implemented in EP 6.0 is based on an ACL solution (Access
Control List), which allows an administrator (object creator) to create a new ACL object and
assign it to the owner.

5.2

Scenarios & Use Cases

The ACL solution provides an interface, which enables the access to the ACL objects and
allows the application to:

Create, modify or delete supported permissions for the ACL solution,

Create, modify or delete an ACL object for a portal object,
Add or remove ACL owners,
Create, modify or delete the permissions for a principal (ACE),
Check if a user has permission to execute an action.

The ACL solution is integrated into the UserManagement Service, which is running on EP 6.0.
The service allows the applications to perform the actions. The collaborative editing of ACL
object is not allowed.

5.3

Application specific ACL Manager

With the default ACL Manager all Acl's and permissions use a common namespace for all
applications that use Acl's. This can cause some conflicts, if someone doesn't pay full
attention to their object ID's and permission names (i.e. doesn't use a object type prefix).
Therefore, UMFactory provides a method getAclManager(String applicationID) , which
gives you an application specific ACL manager. With this manager you have an own
namespace for your application. So no conflicts can occur with other applications that also
use Acl's.
But this also means, you have no access at all to Acl's and permissions of other applications!
5.4

ACL API

The Application that uses the ACL API works with following interfaces:
5.4.1

com.sap.security.api.acl.IAclManager

This interface defines all the methods that are required for the ACL general administration. It
allows application to:

Create, modify, read and delete an ACL object for a portal object,
Check the permission for a principal on an object,
Add, remove and get available supported permissions,

14

Delete the whole corresponding data for a principal.

5.4.2 com.sap.security.api.acl.IAcl
This interface allows application to:

Add or remove an ACL owner

Check if an user is an ACL Owner
Create, delete or get ACE's
Check the user permissions
Check the object ID

5.4.3 com.sap.security.api.acl.IAclEntry
The ACE object stores information about a principal and its permissions. It allows the
application to:

Get the permission and the principal from ACE,

Check if the ACE covers some permission,
Check if the principal has the wanted permission.

5.4.4 com.sap.security.api.acl.PermissionStatus
The permission status object stores information, if the permission is allowed, denied or
undefined for a given principal. The application gets the ACL Manager from PRT, which
illustrates following example:
IAclService service = (IAclService)
PortalRuntime.getRuntimeResources().getService(IAclService.SERV
ICE_ID);
IAclManager manager =

service.getAclManager();

In UM, the application gets the ACL Manager from the UMFactory with the following example:
IAclManager aclManager =

UMFactory.getAclManager();

5.4.5 com.sap.security.api.acl.IAclHierarchy
This Interface provides the application an access point to:

5.5

Check the permission for a principal on a list of object Ids which represent the parent
objects of the former object,
Propagate an ACE to the members of a object ID tree. If you change the ACE for a
root object, this new ACE will be propagated to all members of the sub tree from this
root. All these entries are inherited.
ACL Manager Interface

Definition of an Access Control List Manager

The ACL Manager administers the Access Control Lists (ACL).
This interface defines methods which are necessary to administer ACL's and check if a
principal has access to an object with a certain permission.
Permissions:
- An permission exists of an object type and an permission name separated by by a point '.'
(i.e. "default_type.read" ).

15

Note: A point is not allowed in the object type, but in the permission name!
- Optional: You can use global permissions (permissions without object type)
- Permissions must be unique within the namespace of the ACL Manager you are using. This
means if you use an application specific ACL Manager, the permissions have to be unique
within your application. If you use the default ACL Manager, the permission have to be
globally unique.
Object Id's:
-They also have to be unique within the namespace of the ACL Manager you are using (see
above). Therefore they should have a prefix with the service name and/or the object type.
The following code exsample shows some typical functions:
//Get default ACL Manager
IAclMAnager manager = UMFactory.getAclManager();
// Get specific ACL Manager
IAclMAnager manager = UMFactory.getAclManager("Workflow");

//Create some Permissions

manager.addPermission("WorkflowPermission.read", null);
manager.addPermission("WorkflowPermission.write", null);
//Create a Permission Container
List members = new ArrayList(2);
members.add("WorkflowPermission.read");
members.add("WorkflowPermission.write");
manager.addPermission("WorkflowPermission.full_control", members);

//Create an ACL on an objectID

IUser userA;
IAcl acl = manager.createAcl(userA, "WorkflowItemABC");
//Get this ACL again
IAcl acls = manager.getAcls("WorkflowItemABC");
//Delete an ACL
manager.removeAcl(userA, "WorkflowItemABC");
//Delete all info's abaout a principal (concerning ACL info)
manager.deletePrincipal(usersA);
//Create an ACE (Access Control Entry) for user B (user A is ACL
Owner)
IAclEntry aclEntry = acl.createAclEntry(userA, userB,
"WorkflowPermission.read", false);
//Get all ACE's for a special principal
acl.getAclEntries(userB);
//Get all ACE's
acl.getAclEntries();

//check a permission on IAclManager

manager.isAllowed("WorkflowItemABC", usersA,
"WorkflowPermission.read");

16

//check a permission on IAcl

acl.isAllowed(usersA, "WorkflowPermission.read");
//check a permission on IAclEntry
acl.isAllowed("WorkflowPermission.read");

//Delete an ACL Entry

acl.removeAclEntry(usersA, aclEntries);
//Reset the hole ACL (only deletion of ACE's)
acl.resetAcl(usersA);

17

http://www.sap.com/netweaver