Wednesday, August 28
Thursday, August 15
SAP EP User administration
What is UME? What are UME Action? What are UME roles and what are portal roles? How to map users for single sign on purposes?
UME
UME stands for user management engine. It is a service of SAP EP using which user and user attributes can be maintained. UME can be configured to use few datasources as user bases. Multiple datasources also can be configured using the UME configuration. UME enforces authentication and authorization in SAP EP. Authnetication means validating the user when he is trying to login to SAP EP. Authorization means providing a user with sufficient rights to work with objects within SAP EP. for example, there are 2 iviews say contact details iviews and user data iview on a screen of SAP EP. user data is some information which identifies the user uniquely within a system. As administrators of a system we would not want the user to modify that information so we would provide only read access for the iview to the end user. On the other hand, contact details iview is user's personal information which he can change by logging into SAP EP. To that iview we can provide read, write access. These are called authorizations.
UME action
In order to enforce authorization within portal as explained above, you need to define some actions, permission and roles. To put it simply, some permissions grouped together form action. Some actions grouped together form role. Role are assigned to user or group of users. So ultimately it is the permissions that are being assigned to the user of group of users.
Permissions are defined as code level within the portalapp.xml file. So for each application that gets integrated within the SAP EP, there are a set of permissions defined. Users who would be given those permissions would be able to access those applications through iviews.
Also within the java code of the application, permissions are grouped into actions. Actions are then visible in the administration console on user management and can be grouped together to form a role.
UME roles and portal roles
UME roles are a group of ume actions defined in the java code of an application. There are some standard ume actions available in a fresh enterprise portal. installation. So UME roles serve the purpose of authorization only within the portal. Authorization is based on the actions available within the UME role. portal role on the other hand decides which content is to be made visible to the user who has that portal role. Also it can be assigned ume actions to define authorization. So UME roles are only for authorization while portal roles are for both authorization and content to be displayed to the user.
UME roles can be created using the identity management of portal. Portal roles can be created using the portal content directory tool of portal. UME roles are stored in the User management tables of the J2EE database while portal roles are stored in the PCD tables of J2EE database.
In portal context it is always better to use portal roles because they serve both the purpose of authorization and content assignment.
How to map users for single sign on purposes
We need user mapping to make sure that user is able to access backend system from portal. Enabling the user to do this is called single sign on. And we would require to do mapping of the users only when user ID of the user is not the same in portal and the backend system. If the user ID is same, user mapping would not be needed.
When a portal application tires to access a backend system, portal runtime checks portal system landscape and identifies the system. Then the runtime asks the UME whether a user mapping for the current user for the backend system is available or not. If available, then access to the backend system is granted to the user. There are 2 type of user mappings possible in portal.
User mapping using the logon ticket.
In this type of user mapping, the portal writes backend user ID in the logon ticket that portal issues when an application tries to connect to the backend system. The backend system then reads the user ID from the ticket and authenticates portal user to access the backend system
User mapping using user ID and password
In this type of user mapping, a portal user, group or roles is mapped to a specific ID in the backend system. When a portal user, tries to access the backend system, portal runtime checks with UME whether a mapping between current user and a user ID in the backend is done or not. If not, it checks whether a mapping between the group to which current user belongs to and the backend user ID is done or not. If not, it checks whether a mapping between one of the direct roles of current user and the backend user ID is done or not. Once mapping is found, portal user is allowed to access the backend system.
Related posts
Pointing UME of portal to Active directory
How to change portal runtime mode
SAP enterprise portal user administration
Methods of IUserFactory API and Iuser API
UME
UME stands for user management engine. It is a service of SAP EP using which user and user attributes can be maintained. UME can be configured to use few datasources as user bases. Multiple datasources also can be configured using the UME configuration. UME enforces authentication and authorization in SAP EP. Authnetication means validating the user when he is trying to login to SAP EP. Authorization means providing a user with sufficient rights to work with objects within SAP EP. for example, there are 2 iviews say contact details iviews and user data iview on a screen of SAP EP. user data is some information which identifies the user uniquely within a system. As administrators of a system we would not want the user to modify that information so we would provide only read access for the iview to the end user. On the other hand, contact details iview is user's personal information which he can change by logging into SAP EP. To that iview we can provide read, write access. These are called authorizations.
UME action
In order to enforce authorization within portal as explained above, you need to define some actions, permission and roles. To put it simply, some permissions grouped together form action. Some actions grouped together form role. Role are assigned to user or group of users. So ultimately it is the permissions that are being assigned to the user of group of users.
Permissions are defined as code level within the portalapp.xml file. So for each application that gets integrated within the SAP EP, there are a set of permissions defined. Users who would be given those permissions would be able to access those applications through iviews.
Also within the java code of the application, permissions are grouped into actions. Actions are then visible in the administration console on user management and can be grouped together to form a role.
UME roles and portal roles
UME roles are a group of ume actions defined in the java code of an application. There are some standard ume actions available in a fresh enterprise portal. installation. So UME roles serve the purpose of authorization only within the portal. Authorization is based on the actions available within the UME role. portal role on the other hand decides which content is to be made visible to the user who has that portal role. Also it can be assigned ume actions to define authorization. So UME roles are only for authorization while portal roles are for both authorization and content to be displayed to the user.
UME roles can be created using the identity management of portal. Portal roles can be created using the portal content directory tool of portal. UME roles are stored in the User management tables of the J2EE database while portal roles are stored in the PCD tables of J2EE database.
In portal context it is always better to use portal roles because they serve both the purpose of authorization and content assignment.
How to map users for single sign on purposes
We need user mapping to make sure that user is able to access backend system from portal. Enabling the user to do this is called single sign on. And we would require to do mapping of the users only when user ID of the user is not the same in portal and the backend system. If the user ID is same, user mapping would not be needed.
When a portal application tires to access a backend system, portal runtime checks portal system landscape and identifies the system. Then the runtime asks the UME whether a user mapping for the current user for the backend system is available or not. If available, then access to the backend system is granted to the user. There are 2 type of user mappings possible in portal.
User mapping using the logon ticket.
In this type of user mapping, the portal writes backend user ID in the logon ticket that portal issues when an application tries to connect to the backend system. The backend system then reads the user ID from the ticket and authenticates portal user to access the backend system
User mapping using user ID and password
In this type of user mapping, a portal user, group or roles is mapped to a specific ID in the backend system. When a portal user, tries to access the backend system, portal runtime checks with UME whether a mapping between current user and a user ID in the backend is done or not. If not, it checks whether a mapping between the group to which current user belongs to and the backend user ID is done or not. If not, it checks whether a mapping between one of the direct roles of current user and the backend user ID is done or not. Once mapping is found, portal user is allowed to access the backend system.
Related posts
Pointing UME of portal to Active directory
How to change portal runtime mode
SAP enterprise portal user administration
Methods of IUserFactory API and Iuser API
Subscribe to:
Posts (Atom)