The {@code Authorization} interface encapsulates an authorization context onwhich 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 {@code Authorization} object passed to it possessthe required role, by calling its {@code hasRole} method.
Authorization contexts are instantiated by calling the {@link UserAdmin#getAuthorization(User)} method.
Trusting Authorization objects
There are no restrictions regarding the creation of {@code Authorization}objects. Hence, a service must only accept {@code Authorization} objects frombundles that has been authorized to use the service using code based (or Java 2) permissions.
In some cases it is useful to use {@code ServicePermission} to do the codebased access control. A service basing user access control on {@code Authorization} objects passed to it, will then require that a callingbundle has the {@code ServicePermission} to get the service in question. Thisis 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 {@code 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 {@code Authorization} object), the service explicitly checks that the callingbundle has permission to make the call.
@noimplement
@author $Id: 4786641d1725f18fb3bc160059d7f8b28e46bbab $