Category Archives: oauth

tictactoe swagger,oauth, jsf with cucumber and selenium

Added a project to github today

https://github.com/bernardjason/tictactoe

Screenshot3-Swagger UI - Google Chrome

There is a version running on heroku too see

swagger ui – http://bjason-tictactoe.herokuapp.com/swagger/swagger-ui.html

or the demo game
tictactoe – http://127.0.0.1:8080/swagger/home.xhtml

It’s a springfox swagger implementation of oauth using spring(with hibernate/h2), jsf, cucumber and selenium

Quick note, the tests use Selenium and are set to use Firefox and Chrome. See file JsfFeatureSteps.java in package bjason.swagger.jsf. Also note that to test Chrome at least I’ve had to include copies of chromedrive for Linux. You’ll need copies for other platforms from here https://sites.google.com/a/chromium.org/chromedriver/

The aim of the project was to look at a more recent copy of swagger than I’ve used before. Then to use JSF rather than the usual JSP. Finally I wanted to see the oauth feature built into swagger working. So the implementation features are built around my tool choice and what I wanted to see rather than best way to do it. Biggest “choice” being heavy use of javascript in JSF pages to call rest resources when I think I’d have done that on the backend in this case.

What does the game do? It just allows 2 players to have a game of tic tac toe. It doesn’t check who wins, so it isn’t finished. it just shows the use of a simple rest api.

Note the use of spring profile below, as default is to deploy to heroku (postgress) rather than in memory h2 db.

to run up to play tictactoe as well as see the swagger gui

mvnw clean spring-boot:run -Dspring.profiles.active=local

then visit http://127.0.0.1:8080/swagger/swagger-ui.html

or to play the game

http://127.0.0.1:8080/swagger/home.xhtml

Swagger requires a recent version of the browser, be that Chrome, Firefox or IE. The oauth functionality uses Object.assign which is added in ECMAScript 6th edition.

I’ve included the swagger-ui here, as I’ve tested this works, at least for my 2 browsers, Chrome and Firefox.

To run selenium tests

mvnw package -Dspring.profiles.active=local

selenium

test class JsfFeatureSteps.java sets up the use of 2 browsers. If you aren’t using Chrome or Firefox, or are a
non Linux 64 bit please visit http://www.seleniumhq.org/download/ to see links to the various third party drivers

you may need to change this entry if using windows
System.setProperty(“webdriver.chrome.driver”,
“./chromedriver.” + System.getProperty(“os.name”) + “.”
+ System.getProperty(“sun.arch.data.model”));

to simple reference the drive explicitly, e.g. System.setProperty(“webdriver.chrome.driver”,”chromedrive.exe”);

the test is setup to use 2 browsers, Chrome and Firefox. To change simply set these lines accordingly.
_chromePlayer2 = new ChromeDriver();
_firefoxPlayer1 = new FirefoxDriver();

I chose these browsers simply because they are the 2 I use for testing on my system.

TicTacToeController.java

this file creates the actual game resources. Using lots of swagger annotations it defines the interface alongside the implementation.
It is here that the rest api definitions have their scope’s defined as well. There’s a lot of annotations but the entire api is configured in one place,
then the actual code just implements the api functionality. The authorisation is specified here but actually implemented in CheckBearer.java.

CheckBearer.java

this class extends HandlerInterceptorAdapter and implements the check to ensure the token is valid. Massive cheat here as I use a
spring bean rather than call the check externally via a rest call or similar.
CheckBearer is added as an intercepter in HelloworldApplication..java

OauthController.java

this class implements the rest api’s to support oauth operations. It supports the GET that the tictactoe web app makes to get a token, along
with the POST create of a token that authorization/authorization_server.html uses before it redirects back to the calling tictactoe web app

authorization/authorization_server.html

this page is simply the simple page that the oauth provider implements, here you just enter an email address that isnt validated and it will then
create a token and allow a redirect back to the app using the specified redirect_uri

spring,h2/hibernate

the app is using h2 in memory db to store information about the game in progress.

HelloworldApplication.java

Sets up JSF servlet, adds a logging filter plus adds the CheckBearer for calls to the tictactoe rest resources.

<2h>WEB-INF/ faces-config.xml and web.xml

This is needed just to keep JSF happy. Otherwise not required.

cucumber

setup is via src/test/resources/bjason/swagger/jsf/jsf.feature, and classes CucumberJsfTest.java and JsfFeatureSteps. I’ve described the
scenarios for driving the GUI pages using selenium. Sorry no proper unit tests.

Screenshot6-Swagger UI - Google Chrome

Screenshot5-authorization page - Google Chrome

Screenshot4-authorization page - Google Chrome

Screenshot3-Swagger UI - Google Chrome

Screenshot2-Swagger UI - Google Chrome

Screenshot1-Swagger UI - Google Chrome

ouath2 demo server and client

Oauth api protection has been a hot topic at work, I wanted to make sure I had a firm understanding over and above google.

I found this excellent blog  steeplesoft and had a play with the sample code. It is based on Apache Oltu

You can download the demo application I created based on blog from

https://github.com/bernardjason/playing-with-oauth2.git

I’ve converted the original application to use CXF, as well as using Jetty and some more visual demos. It provides some integration tests to show a CXF client

  • getting a code that has scope to call 2 out of the apis.
  • getting an access_token with scope to call 1 api
  • getting an access_token with scope to call all 2 out of the 3 apis
  • calling the api’s with access_token

to run the integration tests issue maven command

mvn clean package jetty:run

then visit http://127.0.0.1:8080/application

The HTML is simply something to show a possible flow with oauth2. It isn’t secure, this is a demo

The page “http://127.0.0.1:8080/application”

oauth_application

is a fictitious 3rd party who wants to access some API’s you provide to customers.

  • /api/demo/1
  • /api/demo/2
  • /api/demo/3

Click on the top bar “Authorise” and it will redirect the browser to the API authentication page. Here the customer would grant the 3rd party access to some or all of the resources.

oauth_authorise

if this was a full application the customer would have authenticated with username/password onto API provider website.

From the 3 check boxes select an API. I picked 2

oauth_denied

when i tried to call API 1 it denied the request. But when I tried API 2 I was permitted to call the API

oauth_allowed

Of course as it’s oauth access_token the token will expire.  In the case of the demo it is 30 seconds.

The 3rd party has been granted by the customer long term (well 60 seconds for this demo) to some of a customers resources. The access_token is a temporary token to get access to one or more of these resources.

I see its use as

3rd party must be given a client_id and client_secret by API provider or they can do nothing. If this is revoked 3rd party can do nothing.

3rd party must be granted by the customer of the API specific access to their API’s, these may provide personal data or allow an action to be performed on behalf of the customer. Something that would be done infrequently.

3rd party gets an access_token to provide day to day calls to the APIs.