To run this tool you first need to have an instance of the jar. Since the code is not yet in an instance of OpenAM and won't be until version 13 at the soonest, you can download a copy of the jar by clicking this link. Upon clicking that link you'll get the 1.0.1 version of the contributed code in a jar file named openam-auth-radius-1.0.1.jar.
Once you have the jar you run the console client like this:
java -jar openam-auth-radius-1.0.1.jar
The tool needs a configuration file to be located in the current directory named radius.properties. If not found it will write the following to the command line and exit. I've highlighted some interesting parts:
May 15, 2015 2:56:00 PM com.sun.identity.authentication.modules.radius.server.config.RadiusServiceStarter logModuleBuildVersion
INFO: Loaded OpenAM Authn Radius Module = 1.0.1 built 2015-05-12 22:36 UTC
Missing required config file 'radius.properties' in current directory /Users/boydmr/.
Must Contain:
secret=<shared-secret-with-server>
host=<hostname-or-ip-address>
port=<port-on-target-host>
May Contain:
show-traffic=true
Create a radius.properties file with suitable values for your test. For example, as noted I have OpenAM with the radius server enhancement running on my local machine. Therefore I create that file with these values pointing to my local server.
secret=letmein
host=127.0.0.1
port=1812
show-traffic=true
It works equally well going against a server located elsewhere. Now when I run Console Client it will prompt me for username and password before starting the radius conversation. I've entered my values already in this screen capture. You'll have to use a user and password that exist in your environment.
May 15, 2015 3:00:40 PM com.sun.identity.authentication.modules.radius.server.config.RadiusServiceStarter logModuleBuildVersion
INFO: Loaded OpenAM Authn Radius Module = 1.0.1 built 2015-05-12 22:36 UTC
? Username: demo
? Password: password
Now what happens after entering the password depends on if you have defined a client on the server and the nature of the configured flow for this client. You will always see an access-request be sent to the server as shown below. But if, for example, the client is not yet defined, you'll see the following traffic be fired to the server and nothing will happen thereafter. The JVM is waiting for a response that will never come since the radius RFC requires that requests from unregistered IP addresses be dropped silently.
Packet To 127.0.0.1:1812
ACCESS_REQUEST [1]
- USER_NAME : demo
- USER_PASSWORD : *******
- NAS_IP_ADDRESS : localhost/127.0.0.1
- NAS_PORT : 0
If the client is defined on the server with the IP address from which you are making this UDP request but the shared secret is incorrect then that packet to the server will be followed by this console output and the client will exit.
Packet From 127.0.0.1:1812
ACCESS_REJECT [1]
---> Sorry. Not Authenticated.
On the server side for OpenAM it doesn't log this case but simply indicates that an access-reject response was returned. This is because there is no way to distinguish between an incorrect secret and a packet that is corrupted or tampered with. So access is rejected.
If your server issues challenge responses you'll see a response like the following and the client will allow you to enter whatever information is suitable for that challenge, here a one time passcode ostensibly sent via SMS, and wait for you to press the Enter key to send it back to the server.
Packet From 127.0.0.1:1812
ACCESS_CHALLENGE [1]
- STATE : fa66c0a9
- REPLY_MESSAGE : Enter One-Time Passcode (OTP) A one-time validation code has been sent to *******964
---> Enter One-Time Passcode (OTP) A one-time validation code has been sent to *******964
? Answer:
Once you enter your value it will now cause another access-request packet to be sent to the server. But now it also contains the state field if received in the challenge, and its value is unchanged from what it received. Additionally, your answer to the challenge is embedded within the password field.
Packet To 127.0.0.1:1812
ACCESS_REQUEST [2]
- USER_NAME : boydmr
- USER_PASSWORD : *******
- NAS_IP_ADDRESS : localhost/127.0.0.1
- NAS_PORT : 0
- STATE : fa66c0a9
Once all such challenges are successfully answered, or after username and password are entered if no challenges are issued, you will see either an access-accept response indicating that authentication was successful like so:
Packet From 127.0.0.1:1812
ACCESS_ACCEPT [2]
---> SUCCESS! You've Authenticated!
Or you'll see an access-reject like the following:
Packet From 127.0.0.1:1812
ACCESS_REJECT [2]
---> Sorry. Not Authenticated.
In both cases the Console Client will output a suitable message indicating the success or failure as shown and will exit.
Oh, and one caveat on using this jar. If you want to leverage the radius updates in OpenAM it takes a couple more steps than just dropping this version into your WEB-INF/lib directory, removing the old one, and restarting tomcat. That is almost all that there is to it. But not quite. There are two more steps. If anyone wants to give it a test run leave me a comment and I'll add another post illustrating those steps. It isn't hard. I'm just out of time for today. :-)
Enjoy.
No comments:
Post a Comment