Overview | Package | Class | Tree | Serialized | Deprecated | Index | Help
| OSGi Service Platform Release 3
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.osgi.service.useradmin
Interface Authorization

public interface Authorization

The `Authorization` interface encapsulates an authorization context on which bundles can base authorization decisions, where appropriate.

Bundles associate the privilege to access restricted resources or operations with roles. Before granting access to a restricted resource or operation, a bundle will check if the `Authorization` object passed to it possess the required role, by calling its `hasRole` method.

Authorization contexts are instantiated by calling the `UserAdmin.getAuthorization(org.osgi.service.useradmin.User)`method.

Trusting Authorization objects

There are no restrictions regarding the creation of `Authorization` objects. Hence, a service must only accept `Authorization` objects from bundles that has been authorized to use the service using code based (or Java 2) permissions.

In some cases it is useful to use `ServicePermission` to do the code based access control. A service basing user access control on `Authorization` objects passed to it, will then require that a calling bundle has the `ServicePermission` to get the service in question. This is the most convenient way. The OSGi environment will do the code based permission check when the calling bundle attempts to get the service from the service registry.

Example: A servlet using a service on a user's behalf. The bundle with the servlet must be given the `ServicePermission` to get the Http Service.

However, in some cases the code based permission checks need to be more fine-grained. A service might allow all bundles to get it, but require certain code based permissions for some of its methods.

Example: A servlet using a service on a user's behalf, where some service functionality is open to anyone, and some is restricted by code based permissions. When a restricted method is called (e.g., one handing over an `Authorization` object), the service explicitly checks that the calling bundle has permission to make the call.

Method Summary
`java.lang.String` | `getName()` Gets the name of the `User`that this `Authorization` context was created for.
`java.lang.String[]` | `getRoles()` Gets the names of all roles encapsulated by this `Authorization` context.
`boolean` | `hasRole(java.lang.String name)` Checks if the role with the specified name is implied by this `Authorization` context.

Method Detail

### getName

    public java.lang.String getName()

  Gets the name of the `User`that this `Authorization` context was created for.
  Returns:
    The name of the `User`object that this `Authorization` context was created for, or `null` if no user was specified when this `Authorization` context was created.

### hasRole

    public boolean hasRole(java.lang.String name)

  Checks if the role with the specified name is implied by this `Authorization` context.

  Bundles must define globally unique role names that are associated with the privilege of accessing restricted resources or operations. Operators will grant users access to these resources, by creating a `Group`object for each role and adding `User`objects to it.

  Parameters:
    `name` - The name of the role to check for.
  Returns:
    `true` if this `Authorization` context implies the specified role, otherwise `false`.

### getRoles

    public java.lang.String[] getRoles()

  Gets the names of all roles encapsulated by this `Authorization` context.
  Returns:
    The names of all roles encapsulated by this `Authorization` context, or `null` if no roles are in the context. The predefined role `user.anyone` will not be included in this list.

Overview | Package | Class | Tree | Serialized | Deprecated | Index | Help
| OSGi Service Platform Release 3
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright (c) OSGi Alliance (2000, 2003). All Rights Reserved.