using auth in java application

Session ID: CD 261Using Authorizations in Java Application Development

© SAP AG 2005, SAP TechEd ’05 / CD 261 / 2

Contributing Speaker(s)

Elizabeth WinkerKnowledge ArchitectSecurity and Identity Management SAP AG

Patrick HildenbrandProduct Manager SecuritySAP AG

Comparing UME and J2EE Security ConceptsMore About UME Permissions, Actions and RolesHow To Implement…ExerciseSummary


Learning Objectives

As a result of this workshop, you will be able to:

Understand the differences between J2EE security roles andUME permissionsUnderstand how to use UME permissions, actions and roles for enforcing authorizationsInclude UME permissions and actions in a J2EE application


J2EE Security Roles

Characteristics:Abstract logical grouping of usersDefined for one specific applicationDeclarative or Programmatic approaches

Declarative: Container-managed authorization; no programming necessary

Decouples access control from application logic; access control is linked to the resourcesEasy to implement and maintain

Programmatic: Call methods in application to check if user belongs to a specific role.

Access control takes place within codingMore flexible but linked to application logicMore work to implement


J2EE Security Roles: Declarative

EJBe.g. Address

change() display()

ChangeRole

DisplayRole

ChangeGroup DisplayGroup

JAR

EAR

User1 User2


J2EE Permission Checks: Programmatic

Methods:Defined in interface javax.ejb.EJBContext

getCallerPrincipal()Returns the java.security.Principal that identifies the user.

isCallerInRole(java.lang.String roleName)Tests if the caller belongs to a given security role(security role references should be used)


J2EE Security Roles

Characteristics:Name-based association, meaning one security role for each authorizationNo value distinction associated with the role(for example, create, edit, delete)Value distinction only possible with nameThis leads to numerous roles making administration difficultExamples:

DisplayObjectCreateObjectEditObjectDeleteObject


J2EE Security Role References

Characteristics:Consolidate security roles used by individual modules for a complete applicationMaps multiple names to one role

Use security role references in particular when security checks are hard-coded within the business code.

Example: An employee role may be used by multiple modules and naming may vary. For example, one module may use the name EMP for the check, while another may use the name EMPL. The Assembler or Deployer can consolidate these roles using the security role reference EMPLOYEE.


UME Permissions, Actions and Roles

Characteristics:Programmatic approachExtend Java permisssionsAllows for value distinction within a permission checkReduces number of permissions/roles to work withExample:

Additional complexity is hidden by consolidating permissionsinto so-called actions

display()

create()

AddressPermission

change()

delete()

EJBe.g. Address


UME Permissions

How to Use:Extend Java permisssionsPre-defined UME permission classes available

NamePermissionMaps a permission name to a single actionExample: Name=„CreateOrder“

ActionPermissionMaps a permission name to multiple actionsExample: Name=„Order“, Action=„create“

ValuePermissionMaps a permission name to a valueExample: Name=„Min“, Action=„>50“

Check permission in code using eithercheckPermission()hasPermission()


Actions

Collection of Java permissions that describe allowable tasksin an applicationConsolidate permissions for easier administration

Permissions are not visible in administration console

Can be changed without changing/redeploying the applicationGroups into roles to be assigned to users

ACTION 1

Permission 1

Permission 2

ACTION 2

Permission 2

Permission 3


UME Roles

Administrator assigns actions to UME rolesUME roles can contain actions from different applicationsAdministrator assigns UME roles to users

UME ROLE

ACTION 1

Permission 1

Permission 2

ACTION 2

Permission 2

Permission 3


UME Roles - Summary

Created as Java class duringdevlopment

XML file(deployable) User/Role administration

Permission 1

Permission 2

Permission 3

Action 1

Action 2

Action 3

UME Role 1

UME Role 2

UME Role 3Group

User


How to Implement…

First: Determine the permissions to check

Then, implement:1. Preparation: Include UME library

(com.sap.security.api.sda).2. Obtain user information / force authentication.3. Create the permission class.4. Check the permission in the application.5. Rebuild and deploy.


How to Implement…

Next, create actions:Create the actions.xml file.Build archive and deploy.

The administrator can nowCreate UME rolesAssign actions to the UME rolesAssign UME roles to users or groups.


Force Authentication

Use functions provided by the UMFactoryTwo available functions:

getLoggedInUser()forceLoggedInUser()

Use getLoggedInUser() to get an already logged on user‘s ID. If the user is not yet logged on, use forceLoggedInUser() to send logon screen.

Example:IUser user =

UMFactory.getAuthenticator().getLoggedInUser(request, response);if (null == user) {

UMFactory.getAuthenticator().forceLoggedInUser(request, response);return;

}


Permission Class

package com.sap.engine.examples.myappl;import com.sap.security.api.permissions.ActionPermission;

public class MyPermission extends ActionPermission {/**

* @param object* @param action

*/

public MyPermission(String object, String action) {super(object, action);

}}

Recommendation: Extend one of the pre-defined permissionsNamePermissionActionPermissionValuePermission

Example:


Checking the Permission

...

try {user.checkPermission(new MyPermission("order", "create"));

} catch (AccessControlException e) {<process_error>

}...

Use either:checkPermission()

Use to enforce authorization for performing a taskThrows an exception if check fails

hasPermission()Does not throw an exception on failed checkUse to modify screen elements, for example

Example:


Create Actions

Create actions as Development Component (DC)XML file called actions.xmlDeployableCan be changed and re-deployed independent of application

Example


Actions: Example

<BUSINESSSERVICE NAME="MyAppl"><DESCRIPTION LOCALE="en" VALUE="My Application" />

<ACTION NAME="AccessAppl"><DESCRIPTION LOCALE="en" VALUE="Access My Application" /><PERMISSION CLASS="com.sap.engine.examples.myappl.AccessApplPermission"

NAME="access" /></ACTION>

<ACTION NAME="CreateOrder"><DESCRIPTION LOCALE="en" VALUE="Create Orders" /><PERMISSION CLASS="com.sap.engine.examples.myappl.OrderPermission"

NAME="Order", VALUE="Create" /></ACTION>

<ACTION NAME="ApproveOrder"><DESCRIPTION LOCALE="en" VALUE="Approve Orders" /><PERMISSION CLASS="com.sap.engine.examples.myappl.OrderPermission"

NAME="Order", VALUE="Approve" /></ACTION>

<ACTION NAME="MaintainAll"><DESCRIPTION LOCALE="en" VALUE="Perform all actions" /><PERMISSION CLASS="com.sap.engine.examples.myappl.OrderPermission"

NAME="Order", VALUE="Create" /><PERMISSION CLASS="com.sap.engine.examples.myappl.OrderPermission"

NAME="Order", VALUE="Approve" /><PERMISSION CLASS="com.sap.engine.examples.myappl.AccessApplPermission"

NAME="access" /></ACTION>

</BUSINESSSERVICE>


Administration: Create Roles and Assign to Users

Use UME User Administration Console1. Create Roles2. Assign Actions to Roles3. Assign Roles to Users or User Groups

Example of Role/Action Assignment

Role name:Description:

Available Actions: Selected Actions:

MyAppl.AccessApplMyAppl.CreateOrderMyAppl.ApproveOrder

MyAppl.MaintainAll

TopManager

Add >

Add ALL >>

< Remove

<< Remove ALL


Demo

Demo


Summary

UME permissions offer more flexibility than J2EE Security Roles

Multiple values for permissions

Consolidating UME permissions in actions reduces complexity for administration

Unlike J2EE security roles, UME roles are application independent.

When using UME permissions, use the programmingapproach. No support for the declarative approach at present.


Guidelines

Use UME permissions for more flexibility and easieradministration.

Only use J2EE security roles for smaller applications with staticresources.

Perform authentication check on frontend.

Use checkPermission() in the backend to check Permissions(as far back as possible)

Often you do not know how the backend logic is accessed, forexample, over a Web service.

Use hasPermission() in the frontend client to modify screenelements based on a user‘s permissions

Do not mix J2EE security roles (declarative) with UME permissions (programmatic).


Further Information

Public Web:www.sap.comSAP Service Marketplace: service.sap.com/securitySAP Developer Network: www.sdn.sap.com Security

SAP NetWeaver Security Tutorial Series: Using Roles and Permissions in Applications

SAP Customer Services Network: www.sap.com/services/

Related Workshops/Lectures at SAP TechEd 2005AGS101 An Overview of User Management and Authorizations LectureAGS351 User Management and Authorizations in Detail Hands-On

Related SAP Education Training Opportunitieshttp://www.sap.com/education/

ADM200 SAP Web AS Java Administration


Questions?

Q&A


Please complete your session evaluation.

Be courteous — deposit your trash, and do not take the handouts for the following session.

Feedback

Thank You !


Copyright 2005 SAP AG. All Rights ReservedNo 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, and PowerPoint are 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 MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, 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 contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided 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 have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. 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.

using auth in java application

Documents