User Administration Service

If you want to protect the access to resources managed by your application, you need a user administration. The aim of a user administration is to define and manage roles, users and groups. Ripla provides the org.ripla.useradmin bundle for user administration. This bundle is an implementation of the OSGi user admin service (see OSGi Service Compendium, 107).

If a user logs into the application, he gets a role based on his membership in groups. Using the Ripla Permission Service, controllers can restrict the access to the resources they control based on permissions they define. If a logged in user is member of a group that is member of the permission group controlling the resource, that user is allowed to access the specified resource.

See the Demo application as an example. The Demo application creates two users: admin and user. In addition, the application creates a user group ripla.admin.group and adds the admin user as required member to this group. The Configuration use case bundle creates a permission entry with a permission group config.skin and declares the user group ripla.admin.group as basic member of this permission group (see Permission Service). Thus, every member of ripla.admin.group is allowed to access the resources that require the config.skin permission. Because admin is the only member of ripla.admin.group, the select skin configuration is available only to the user that logs in as admin.

The bundle defining the permission (in this example the Configuration use case) has to know about the available user groups for that it can link the permission to the user administration.

Enabling User Administration

The org.ripla.useradmin bundle does not contain an OSGi component description, thus, it does not register itself as implementation and provider for the org.osgi.service.useradmin.UserAdmin service.To enable user administration, you have to create a bundle that does the following:

1. Import the package org.ripla.useradmin.admin.

2. Create a class that implements org.osgi.service.useradmin.UserAdmin and extends org.ripla.useradmin.admin.RiplaUserAdmin. E.g.:

public class DemoUserAdmin extends RiplaUserAdmin implements UserAdmin {
    public DemoUserAdmin() throws Exception {
        super();
    }
}

3. Create a component description that declares the class created in step 2 as implementation class. E.g.:

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.ripla.demo.useradmin">
   <implementation class="org.ripla.demo.useradmin.internal.DemoUserAdmin"/>
   <service>
      <provide interface="org.osgi.service.useradmin.UserAdmin"/>
   </service>
   <reference cardinality="1..n" interface="org.osgi.service.prefs.PreferencesService" bind="setPreferences" unbind="unsetPreferences" name="preferences" policy="dynamic"/>
</scr:component>

4. Add the manifest header Service-Component to the bundles MANIFEST.MF:

Service-Component: OSGI-INF/useradmin.xml

See the bundle org.ripla.demo.useradmin as an example.

Permission Initialization

To link the permissions registered at the permission service to the user administration, you have to ensure that all registered permissions are initialized. To do that, call RiplaApplication.initializePermissions(). This will create a permission group for each registered IPermissionEntry and add the members defined in those permission instances.

The best place to do this is your application class' method that binds the user admin service to the application.E.g.:

public class DemoApplication extends RiplaApplication {
//...
    public void setUserAdmin(final UserAdmin inUserAdmin) {
        super.setUserAdmin(inUserAdmin);
        Group lAdministrators = (Group) inUserAdmin.createRole("ripla.admin", Role.GROUP);
        initializePermissions();
    }
}