Professional Documents
Culture Documents
Lab 10
Following servers needs to be running before you start this Lab (start if not running - refer to
Lab 0 for more details on starting/stopping servers):
You may have to start/stop/restart additional servers as per instructions in this lab.
All passwords used during this Lab are Oracle123 unless otherwise specified
Disclaimer : The Virtual Machine (or hosted) Image and other software are provided for use only
during the workshop. Please note that you are responsible for deleting them from your
computers before you leave. If you would like to try out any of the Oracle products, you may
download them from the Oracle Technology Network
(http://www.oracle.com/technology/index.html) or the Oracle E-Delivery Web Site
(http://edelivery.oracle.com)
Contents
Lab Introduction
In this lab we will go through how to develop and deploy the OAM authentication plug-in. We
will use the custom authentication plug-in with both ECC and DCC webgates.
This lab is based on the sample code found on OTN at
http://www.oracle.com/technetwork/indexes/samplecode/id-mgmt-1884959.html
Note: You need to complete Lab1 before proceeding with this lab.
MFASamplePlugin
This plugin demonstrates the MFA uses cases. On the login page, if either username or pas s-
word is not submitted, this plugin returns a PAUSE status and forwards or redirects back for
credential collection.
This also shows how error/client plugin responses can be sent to the error/login page.
Plugin Configuration Parameters:
actiontype: This plugin configuration parameter indicates how the plugin wants to direct to
the login page to collect credentials. It determines if the plugin wants to perform a forward or a
redirect to the login page.
FORWARD: Plugin assumes that in the case of ECC, the sample login WAR is deployed within
the same container as the OAM managed server and hence the plugin forwards to the login
page.The MFASamplePlugin uses UserAction to forward to the login page.
REDIRECT_GET: Plugin assumes that in the case of DCC, the sample login WAR is deployed in
an external container and hence the plugin redirects to the login page. The MFASamplePlugin
uses UserAction to redirect (with a GET operation) to the login page.
Note: The same UserAction class is used to forward or redirect to the login page. The
actiontype Parameter is used to determine the action (forward vs. redirect).
SampleAuthPlugin
This plugin demonstrates the authentication use case. It also shows examples of how primary
error codes and secondary error messages can be sent to the login/error page. This plugin uses
the username and password that were collected by the MFAPlugin. This plugin also demon-
strates how tokens, query string parameters, headers, etc. can be received from the request.
felix.jar
identity-provider.jar
oam-plugin.jar
utilities.jar
Note: You can open the project in JDeveloper by loading SamplePlugin.jws which is supplied as
part of the sample.
Summary – This section discusses about the plug-in development and functionality of supplied
sample. The sample is located in /app/dummydata/Lab10. The sample is also available on OTN
using the link mentioned in the introduction section of this lab.
Steps
4. Click on Browse
12. Now Click on Refresh , You should see the status as Distributed
Note: If you don’t see the plug-in scroll down to end, refresh again and drag the scroll bar
again to see the imported plug-ins.
13. Scroll down and notice the parameter Action Type and Login Page. We will be deploying the
custom WAR for login page later.
14. Now highlight the plug-in again and click on Activate Selected.
15. Click on Refresh again and make sure that the status is Activated
16. Now we need to distribute and active the second plug-in. Search for Sample
18. Click on Refresh. The status should be now Distributed. Select the plug-in again and click on
Activate Selected
19. Refresh again and make sure that the status is Activated
Summary – In this section we have imported the custom authentication plug-ins , Distributed
and activated the plug-ins.
1. In the OAM Console navigate back to Launch Pad and select Authentication Modules under
Plug-ins
8. You should see the plug-ins as shown. Click on Steps Orchestration tab
9. Specify the Initial Step as MFAStep. The success result of MFA Step should be AuthStep.
Also update the other status as shown.
Summary – In this section we have configured an authentication module used for performing
authentication later in this lab.
Steps
Summary – In this section we have deployed the custom login page application (WAR)
Steps
Name: ECCMFAAuthScheme
Auth Level : 2
Challenge Method : Form
Authentication Module: MFAAuthModule
Challenge URL : /pages/MFALogin.jsp
Challenge Redirect URL : /oam/server
Context Type : customWAR
Context Value : /SampleLoginWAR
Challenge Parameters: initial_command=NONE
Note: The challenge parameter is needed so that the auth scheme can indicate what all crede n-
tials are required to be collected. In this example, the MFASample Plugin looks for
“form_username” and “form_password” parameters. Normally for FORM based mechanisms,
the framework expects "username" and "password" to be submitted from the login page.
In case the auth scheme needs different form fields to be collected from the login page, it needs
to set this challenge parameter, so that instead of directly going to the login page, the control
first comes to the plugin. The plugin can decide that name of parameters it wants to collect
from the login page and appropriately forward or redirect to the page.
23. Now let’s associate this authentication scheme with Authentication Policy. Navigate back to
Launh Pad and click on Authentication Domains under Access Manager
24. Search for domains and click on webgate_1 to open it. We are using the ECC webgate for
this sample.
25. Navigate to Authentication Policies tab and Open the Protected Resource Policy.
26. Change the Authentication scheme to ECCMFAAuthScheme . Click Apply to save the change.
Summary – In this section we have configured the authentication scheme and updated the
resources to use the newly created authentication scheme.
Steps
Note: If you have completed the Lab1, you might have changed the password of user
JKRAUSE. You can reset the password to Oracle123 using an LDAP browser or use the
updated password.
31. You should be able to see the page
32. Scroll the terminal from which OAM server has started, you can see the messages from plug-
in
Summary – In this section we have tested the plug-in using the ECC web gate.
ECC mode - “/oam/server/auth_cred_submit”. This is the OAM server end point the log-
in app posts the data to.
Steps
3. Navigate to WEB-INF
cd WEB-INF
4. Open the web.xml file
gedit web.xml
5. Change the serverPostURL to
http://identity.oracleads.com:7778/oam/server/auth_credit_submit
12. Click again on SampleLoginWAR and click Delete to delete the deployment
13. Now click on the Install button to install the WAR again
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster identity.oracleads.com:14100
</Location>
<Location /mybank>
SetHandler weblogic-handler
WebLogicCluster identity.oracleads.com:14100
</Location>
Summary – In this section we have updated the War file for using with DCC webgate and we
have also updated the module conf in OHS so that it can direct the requests to OAM.
3. Click on Create
Name: DCCMFAAuthScheme
Auth Level : 2
Challenge Method : Form
Authentication Module: MFAAuthModule
Challenge URL :
http://identity.oracleads.com:7001/SampleLoginWAR/pages/MFALogin.jsp
Challenge Redirect URL : http://identity.oracleads.com:7778
Context Type : external
Challenge Parameters: extracreds=cookie:DCCTestCookie
creds=form_username form_password
Note: The “creds” indicate the mandatory parameter that the DCC needs to collect from
the login page. When the login page posts to the DCC URL, the DCC checks if the manda
tory parameters are available and then passes them to the server.
The “extracreds” specifies all the optional parameters that the DCC needs to set. This
cookie name is given, since the SampleAuthPlugin looks for a cookie “DCCTestCookie”.
The DCC checks if this cookie is set and if so, it makes it available to the plugin. This is not
a mandatory parameter, and is used only because the plugin reads this cookie.
5. Next we need to update the parameters of Authentication Module MFAAuthModule for DCC
webgate.
Steps
Note: We are redirecting the User to Error defined in Sample WAR file when
authentication error happens.
5. Now we need to define OAM Server resources as excluded resources. Click on the Resources
tab and click on Create
Note: We are using the DCC web gate which is installed on 7778. The host identifier is
webgate_2
7. Follow the same procedure and define the following resources as excluded resources.
Note: if any of the resource is already defined, ignore that from the above list. Some of
these might have defined in Lab1.
Summary – In this section we have updated the authentication policy to use newly created
authentication scheme and we have also defined resources that needs to be excluded.
Steps
5. It should take you to the successful snoop page. Scroll down and observe that the Cookie set
as part of the Authentication scheme (Under Challenge Parameters:
extracreds=cookie:DCCTestCookie) is propagated to this page after successful login
10. Update the mobile number to 5 or more digits and you should be able to login.
Summary – In this section we have tested the DCC webgate with custom login page .We have
also seen the custom error getting propagated to login page through the plug-in.