Unwired Accelerator uses fine-grained access control. Mobile Web Studio users need permission to perform operations on objects.
Operations – such as create, delete, and execute
Objects – such as applications, pages, and page groups
Through Mobile Web Studio, you can create roles with the appropriate permission, and can create user accounts to which are assigned one or more role. Unwired Accelerator includes several pre-defined roles. You can use these roles as is, use them as a base to create other roles, or create your own roles. The StudioAdmin role has all of the Mobile Web Studio permissions enabled.
Table 7-1 describes Unwired Accelerator’s basic security infrastructure.
Security item |
Description |
|---|---|
Roles (Mobile Web Studio permission) |
The StudioAdmin user creates and administers roles in Mobile Web Studio. Mobile Web Studio roles are modeled after J2EE roles, and grant 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 7-2 for information about the roles used in Unwired Accelerator, and see Table 7-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 5, “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.
