The Openwings Security Service is the entity that controls users
and roles in Openwings. Secure connectors and applications talk
to this service to perform user authentication. There is one Security
Service per platform. The Security Service user interface (UI)
may be accessed from a tree view in the Openwings Explorer.
Expand the openwings_Security process node, and you will be able
to view the net.openwings.security.SecurityService service node,
which expands to show the SecurityPanelUIFactory. Double-clicking
this UI will bring up the user interface for this service. Note
that in the Openwings 1.0 reference implementation, the security
service is configured to only accept calls from the local platform,
so if you attempt to make modifications to the users and roles
on a remote platform, it will fail.
When the Security Service UI appears, it should look like the
figure below. There are two tabs, Users and Roles. The Users tab
shows the users configured on this platform. As mentioned earlier,
Openwings comes with a default user named "openwings".
Clicking on the Roles tab will show the Openwings roles configured
on this platform. Openwings uses a role-based access control (RBAC)
system to control remote access to services. Each user is assigned
one or more roles. Typically, access to services is configured
in Java security policy files for services that provide components.
Service access is usually granted to roles rather than to specific
users.
Openwings comes with three default roles:
- ow_user. This role applies to the ordinary user. Typically
this role will have a lot of access to application-level services
such as the Openwings demonstration components, but limited,
or "observer", access to Openwings core services such
as the Container Manager, Installer, and Context service for
a given platform.
- ow_admin. This role applies to users who will be running
the Openwings core and administering the Openwings installation
on a given platform. This role will typically have unlimited
access to core services such as the Container Manager and Installer,
but limited "observer" access to the Context service.
- ow_context_admin. This role applies to users who will
be administering an Openwings context. This role will typically
have unlimited access to the Context service and limited "observer"
access to other core services such as the Installer and Container
Manager.
Return to the Users tab, click on a user to select it, and click
the Modify User button. A dialog will appear showing the roles
assigned to the user. By default, the "openwings" user
has all three roles, meaning that it will have unlimited access
to demo component services, as well as core services such as the
Container Manager, Installer, and Context Service. The check boxes
provide the ability to select which roles are assigned to a given
user.
Clicking the "Change Password..." button
allows you to change the user's login password.
The Security Service also supports the ability to add users and
roles. To add a new user, select the Users tab and click the Add
User button. The figure below shows the dialog that appears.
This example shows the creation of a user named "Homer"
who is being granted the "ow_user" and "ow_admin"
roles. Keep in mind that user names are not case-sensitive, but
passwords are.
To create a new role, select the Roles tab in the main window
and click the Add Role button. A dialog will appear where you
can enter the name of the new role.
Users on this platform may now be assigned this role.
Other functions supported by the Security Service GUI include
deletion of roles and users.
In the current implementation, roles are by default equivalent
to one another across platforms. This is due to the fact that
Openwings ships with a default Keystore, and the entity that validates
roles has the same KeyPair stored in this Keystore. If the keystore
is replaced or changed, then a signing entity possessing a valid
KeyPair must be created in the KeyStore and the location of that
KeyStore set as a property in ${OW_HOME}/openwings-1.0/policies/properties.txt.
The next page of this trail will discuss more administrative
details - how to configure what permissions are granted to each
role for each of the Openwings core services.
Next: Administering
Service Security for the Core
