Skip to content

Latest commit

 

History

History
214 lines (170 loc) · 9.63 KB

README.adoc

File metadata and controls

214 lines (170 loc) · 9.63 KB
Raw

ejb-security-programmatic-auth: Using the programmatic API to invoke a remote EJB using different identities

The ejb-security-programmatic-auth quickstart demonstrates how to programmatically setup different identities when invoking a remote secured EJB.

What is it?

The ejb-security-programmatic-auth quickstart demonstrates how to invoke a remote secured EJB using the Elytron client API to establish different identities. The quickstart client application accomplishes that by looking up and invoking the secured EJB under different `AuthenticationContext`s. Each context is setup to use a different identities and credentials.

Configure the Server

You configure the security domain by running JBoss CLI commands. For your convenience, this quickstart batches the commands into a configure-elytron.cli script provided in the root directory of this quickstart.

  1. Before you begin, make sure you do the following:

  2. Review the configure-elytron.cli file in the root of this quickstart directory. This script adds the configuration that enables Elytron security for the quickstart components. Comments in the script describe the purpose of each block of commands.

  3. Open a new terminal, navigate to the root directory of this quickstart, and run the following command, replacing WILDFLY_HOME with the path to your server.

    $ WILDFLY_HOME/bin/jboss-cli.sh --connect --file=configure-elytron.cli
    Note
    		 For Windows, use the WILDFLY_HOME\bin\jboss-cli.bat script.

    You should see the following result when you run the script.

    The batch executed successfully
process-state: reload-required

  4. Stop the WildFly server.

Review the Modified Server Configuration

After stopping the server, open the WILDFLY_HOME/standalone/configuration/standalone.xml file and review the changes.

  1. The following application-security-domain mapping was added to the ejb3 subsystem:

    <application-security-domains>
    <application-security-domain name="quickstart-domain" security-domain="ApplicationDomain"/>
</application-security-domains>

    The application-security-domain essentially enables Elytron security for the quickstart EJBs. It maps the quickstart-domain that was set in the EJBs via annotation to the Elytron ApplicationDomain that will be responsible for authenticating and authorizing access to the EJBs.

  2. The http-connector in the remoting subsystem was updated to use the application-sasl-authentication authentication factory:

    <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm" sasl-authentication-factory="application-sasl-authentication"/>

    This allows for the identity that was established in the connection authentication to be propagated to the components.

Access the Application

Before you run the client, make sure you have already successfully deployed the EJBs to the server in the previous step and that your terminal is still in the same folder.

Type the following command to execute the client.

$ mvn exec:exec

Investigate the Console Output

When you run the mvn exec:exec command, you see the following output. Note there may be other log messages interspersed between these.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Called secured bean, caller principal quickstartUser

Principal has admin permission: false
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Called secured bean, caller principal quickstartAdmin

Principal has admin permission: true
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

As expected, the quickstart user is able to call the methods available for guest, but does not have the admin permission to call administrative methods on the remote EJB. The quickstartAdmin on the other hand has permissions to call both methods.

This script reverts the changes made to the ejb3 and remoting subsystems. You should see the following result when you run the script.

The batch executed successfully
process-state: reload-required

  • Make sure you add the authorized application and management users as described above.

  • Make sure you configure the server by running the JBoss CLI script as described above under Configure the Server.

  • Right-click on the {artifactId} project and choose Run As → Maven build. Enter clean package wildfly:deploy for the Goals and click Run. This deploys the {artifactId} JAR to the WildFly server.

  • Right-click on the {artifactId} project and choose Run As → Run Configurations…​.

  • Enter exec:exec for the Goals and click Run.

  • Review the output in the console window. You should see the following output.

    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Called secured bean, caller principal quickstartUser
Principal has admin permission: false
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Called secured bean, caller principal quickstartAdmin
Principal has admin permission: true
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  • To undeploy the project, right-click on the {artifactId} project and choose Run As → Maven build. Enter wildfly:undeploy for the Goals and click Run.

  • Make sure you restore the WildFly standalone server configuration when you have completed testing this quickstart.