Secure OSGi applications

Secure OSGi applications is very similar to securing enterprise applications. For most security frameworks, no additional steps are required. For Java 2 security, there is some optional extra configuration that is specific to OSGi Applications.

For most security frameworks supported by WebSphere Application Server, configuring security for OSGi applications requires no additional steps to those that are required for enterprise applications. For example: If we enable security, and we add a secure asset, specify a target server that is in the global security domain. This requirement is the same whether the asset is an enterprise application or an OSGi application.

For application security with OSGi applications, we can modify the security role to user or group mapping when we add the asset to the business-level application.

For Java 2 security in enterprise applications, we set permissions at the application level. For OSGi applications, we can also set Java 2 security permissions at the bundle level. To support this finer-grained security, there are extra configuration steps that we can complete when creating an OSGi application, when we migrate an enterprise application to an OSGi application, and when we add an enterprise bundle archive (EBA) asset to a business-level application.

Tasks

• Use application security with OSGi applications.

  Application security controls which users may access which parts of the application. See Application security.

  • Modify the security role to user or group mapping.

    We can modify this mapping when we add the asset to the business-level application as a composition unit. See Add an EBA asset to a composition unit by , Add an EBA asset to a composition unit using wsadmin commands, and Security role to user or group mapping [Settings].

  • Use application security with web application bundles (WABs).

    You secure WABs in the same way that you secure web applications in Java EE. Application security enforces any security constraints defined in the web.xml file for a WAB. When a web client tries to access a protected resource, the client is prompted for authentication.

  • Configure bean security in the Blueprint XML file.

    We can configure bean security in the Blueprint XML file of our OSGi applications, so that the methods of the bean can be accessed only by users assigned a specified role. We can configure bean-level security, so that a single role is associated with all the methods of the bean, or we can configure method-level security, where different roles are associated with specific methods.

  • Use application security with EJB bundles.

    You secure enterprise beans in EJB bundles in the same way that you secure enterprise beans in Java EE. Application security enforces any bean method security settings defined in the ejb-jar.xml file for an EJB bundle.

• Use Java 2 security with OSGi applications.

  Java 2 security controls access to protected system resources from the application.

  • Learn about using Java 2 security with OSGi applications.

    Use Java 2 security in OSGi applications is very similar to using Java 2 security in enterprise applications. For more information about Java 2 security in enterprise applications, see Java 2 security. For an overview of the main differences when we use Java 2 security in an OSGi application, see Java 2 security and OSGi Applications. This topic describes the following differences:

    • The format and locations of the permissions.perm files in an OSGi application.

    • The relationship between application-level permissions.perm files in OSGi applications and was.policyfiles in enterprise applications.

    • The default permissions that apply to every OSGi application, in addition to any provided through a permissions.perm file.

  • Configure Java 2 security for our OSGi application.

    1. Create permissions.perm files. For more information, see Java 2 security and OSGi Applications.

    2. Check the security permissions. The security permissions are displayed when we import the OSGi application as an asset. For more information, see Deploy an OSGi application as a business-level application.

  • Migrate Java 2 security settings as part of migrating an enterprise application to an OSGi application.

    When we convert an application from Java EE to OSGi, any existing was.policy file is converted into a permissions.perm file to be used with the OSGi permissions framework, and all permissions are promoted to the application level. If we need finer granularity, we can modify the file after conversion. For more information, see Java 2 security and OSGi Applications, and Converting an enterprise application to an OSGi application.

Related:

Java 2 security and OSGi Applications

Java 2 security

Application security

Blueprint security and OSGi applications

Deploy an OSGi application as a business-level application

Add an EBA asset to a composition unit by

Add an EBA asset to a composition unit using wsadmin commands

Converting an enterprise application to an OSGi application

Security role to user or group mapping [Settings]

File name: was2981.html

prettyPrint();