Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 3. Propagating an identity from a Servlet to a Jakarta Enterprise Bean when using OIDC
You can propagate the security identity obtained from an OpenID Connect (OIDC) provider from a Servlet to Jakarta Enterprise Beans in two ways:
- Using the same virtual security domain to secure both Servlet and Jakarta Enterprise Beans.
- Propagating the identity from a virtual security domain associated with a Servlet to the security domain securing Jakarta Enterprise Beans.
3.1. Identity propagation to Jakarta Enterprise Beans when using OIDC
When you secure an application with OpenID Connect (OIDC), the elytron-oidc-client subsystem automatically creates a virtual security domain for you. You can propagate the security identity in the virtual security domain, obtained from the OIDC provider, to Jakarta Enterprise Beans that your application invokes.
The following table illustrates the required configurations depending on the security domain you use and how the applications are deployed.
| Security domain to use to secure Jakarta Enterprise Beans | Servlet and Jakarta Enterprise Beans are in the same WAR or EAR | Servlet and Jakarta Enterprise Beans are in different WAR or EAR |
|---|---|---|
| Virtual security domain | No configuration is required. The virtual security domain automatically outflows the security identity to the Jakarta Enterprise Beans provided that no security domain configuration has been explicitly specified for the Jakarta Enterprise Beans. | Configure as follows:
|
| A different security domain | To outflow a security identity from a virtual security domain to another security domain, you must configure the following resources:
For more information, see Propagating identity from virtual security domain to a security domain. | |
3.2. Securing Jakarta Enterprise Beans applications using virtual security domain
You can use the virtual security domain created by the elytron-oidc-client subsystem to secure Jakarta Enterprise Beans both when the Jakarta Enterprise Beans is located in the same deployment as the Servlet that invokes it, and when they are located in different deployments.
If the Jakarta Enterprise Beans is located in the same deployment as the Servlet invoking it, no configuration is required to outflow a security identity from the Servlet to the Jakarta Enterprise Beans.
Follow the steps in this procedure to outflow a security identity from a Servlet to Jakarta Enterprise Beans that are located in different deployments.
Prerequisites
- You have secured the application from which you invoke the Jakarta Enterprise Beans using an OpenID Connect (OIDC) provider.
- You have created the Jakarta Enterprise Beans to secure.
Procedure
Create a
virtual-security-domainresource referencing the WAR that contains the Servlet secured with OIDC or the EAR that contains a subdeployment that is secured with OIDC.Syntax
/subsystem=elytron/virtual-security-domain=<deployment_name>:add()Example
/subsystem=elytron/virtual-security-domain=simple-ear-example.ear:add()
Add
org.jboss.ejb3.annotation.SecurityDomainannotation in the Jakarta Enterprise Beans application referencing the virtual security domain resource to use to secure the application.Syntax
@SecurityDomain("<deployment_name>")Example
... @SecurityDomain("simple-ear-example.ear") @Remote(RemoteHello.class) @Stateless public class RemoteHelloBean implements RemoteHello { @Resource private SessionContext context; @Override public String whoAmI() { return context.getCallerPrincipal().getName(); } }If you invoke this Jakarta Enterprise Beans from a Servlet secured with OIDC, the principal returned by
whoAmI ()will match the principal the Servlet obtained from the OIDC provider.Deploy the Jakarta Enterprise Beans.
Example
$ mvn wildfly:deploy
Additional resources
3.3. Propagating identity from virtual security domain to a security domain
You can propagate the security identity from a virtual security domain, obtained from an OpenID Connect (OIDC) provider to a different security domain. You might want to do this if you want the security identity’s roles to be determined by the security domain you propagate the identity to and not the virtual security domain.
The steps in the following procedure apply both when the Servlet invoking a Jakarta Enterprise Beans and the Jakarta Enterprise Beans are in the same deployment and when they are in separate deployments.
Prerequisites
- You have secured the application from which you invoke the Jakarta Enterprise Beans using an OIDC provider.
- You have created the Jakarta Enterprise Beans to secure.
- You secured the Jakarta Enterprise Beans with a security domain.
Procedure
Create a
virtual-security-domainresource referencing the WAR that contains the Servlet secured with OIDC or the EAR that contains a subdeployment that is secured with OIDC.Syntax
/subsystem=elytron/virtual-security-domain=<deployment_name>:add(outflow-security-domains=[<domain_to_propagate_to>])
Example
/subsystem=elytron/virtual-security-domain=simple-ear-example.ear:add(outflow-security-domains=[exampleEJBSecurityDomain])
Update the security domain configuration for the Jakarta Enterprise Beans to trust the
virtual-security-domain.Syntax
/subsystem=elytron/security-domain=<security_domain_name>:write-attribute(name=trusted-virtual-security-domains,value=[<deployment_name>])
Example
/subsystem=elytron/security-domain=exampleEJBSecurityDomain:write-attribute(name=trusted-virtual-security-domains,value=[simple-ear-example.ear])
Reload the server.
reload
Deploy the Jakarta Enterprise Beans.
Example
$ mvn wildfly:deploy
Additional resources
