Unwired Accelerator allows users to see only those objects for which they have the necessary roles. For example, if Application_1 is protected by Role_A, and a user is not assigned Role_A, when the user selects Build | Applications, Application_1 does not display in the Application Manager list of applications.This prevents Mobile Web Studio users from previewing an application they are not allowed to see in Portal Interface or from a mobile device.
If an object is assigned several roles, a user needs only one
of the roles to access the object.
Controlling access to a data source is called access control; assigning permissions to users or groups of users to access secured objects is called authorization.
Table 6-1 describes Unwired Accelerator’s basic security infrastructure.
Security item |
Description |
|---|---|
Roles (permissions) |
The StudioAdmin user creates and administers roles in Mobile Web Studio. Roles are based on J2EE roles, and are granted access permissions to objects, such as pages, applications, catalogs, and so on. Objects are mapped to operations, such as create, edit, manage, and so on. See Table 6-2 for information about the J2EE roles used in Unwired Accelerator, and see Table 6-3 for information about objects and their operations. |
Users (accounts) |
The StudioAdmin user creates and administers user accounts in Mobile Web Studio. Each user account is assigned one or more roles, which grants the user access to various objects with permission to carry out specific operations. Portal Interface users are created automatically when the users sets up an account from the Join Now link on the log in screen. Portal Interface users are not granted access to Mobile Web Studio objects. |
Resources (co-brand) |
Users may be associated with one or more resource, or co-brand. Resources can represent companies, divisions, departments, languages, and so on. If a user is associated with more than one resource, the user must specify the resource identifier (RID) when logging in to Mobile Web Studio, Portal Interface, or a mobile device. See Chapter 4, “Resources” for more resource information. |
To set up role-based security in the portal, an administrator logs in to Mobile Web Studio using the StudioAdmin account, such as masuper, and creates the appropriate security roles and users. For example, the StudioAdmin might create the StudioDeveloper, StudioDesigner, and PortalUser roles, and give the StudioDeveloper role “create” permissions on the “application” object.
The StudioAdmin creates the user accounts and assigns each user the appropriate role. For example, the administrator assigns the StudioDeveloper and PortalUser roles to a user named “Smith.” When user Smith logs in to Mobile Web Studio, CSI verifies the user’s identity, and limits the information the user is allowed to see, modify, or execute. Smith creates an application, which is allowed because he is assigned the StudioDeveloper role that has that access right.
When Smith creates the application, he assigns roles to the application that a user must have to access it. Smith sees all of the roles defined in Mobile Web Studio, including those roles for which he does not have access. This allows him to assign roles that he does not have to protect the application. All users that have the roles assigned to the application, can access that application. See “Working with secure applications” for more information about working with applications that use sensitive or confidential data.
Although Smith sees all J2EE roles when creating an
object, he sees only the Mobile Web Studio objects that the StudioDeveloper
and PortalUser roles have permission to see.
In summary, roles are assigned permissions to view and act on specified objects. User access to objects is controlled by the roles the user is assigned.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
