This is an implementation for IBM Domino of the endpoints needed by the AngularJS ngOauth2AuthCodeFlow module. The endpoints are implemented as standard Domino Spring controllers, thanks to the domino-spring project.
This allows you to host on your Domino Server a set of Databases that contains pure html/css/javascript code. Have a look at the sample database present in this repository's code for more details. Such databases are not using XPages, or good old "Forms and Views" to generate the user interface. They are using AngularJS code with normal calls to $http and $resource to access Rest services exposed into a OAuth2 Resource Server (maybe the Domino Server itself).
oauth2-dom-res-server gives you a mean to implement such services on Domino.
Spring, through its spring-security-oauth project, also offers you an easy way to implement such services in regular java webapps. You can find an example here.
And if you ask me "Why should I store such code into a Notes database ?", then this repository is not for you :) I will publish later a simple repository with a sample that does the same thing using a standard Spring Webapp (using spring-security-oauth).
Once everything is installed and configured, the endpoints (needed to initialize ngOauth2AuthCodeFlow) will be the following :
- "/init" endpoint : http://youserver/anydb.nsf/oauth2-client/login
- "/tokens" endpoint : http://youserver/anydb.nsf/oauth2-client/tokens
- "/refresh" endpoint : http://youserver/anydb.nsf/oauth2-client/refresh
Refer to the README of the dom-spring project for detailed instructions.
The update site is (or will be made) available on the github release page.
Once downloaded, the procedure is the same as installing the dom-spring plugins.
This project is using dom-spring. Refer to the README of this project for more information.
With OAuth2, the browser will load the web interface, detect that it does not have an access token, and then redirect to the authorize endpoint of your authorization server (ADFS, or Google Cloud or Domino Authorization Server for example). The user will log on this server, after which the authorization server will redirect back again the browser to the original page.
In conclusion : If your database is protected by an ACL, the user will have to authenticate twice :
- The first time when accessing the database : Because of Domino ACL, you will have the Domino login screen.
- And again when opening a session on the OAUTH2 authorization server (Your Microsoft ADFS for example) : You will have the ADFS login screen.
For this reason, it is necessary to set Anonymous to reader in the ACL of the database that host the front end code. Then, write Domino hosted Rest Services using oauth2-dom-res-server, and protect them with the access token.
Your database MUST have a view named "Oauth2ClientParams". And this view MUST contain at least one document (only the first one will be used). If this is not the case, the endpoints will not be made available at your database context (you will have a 404 error).
For security reason, it is recommanded to protect the configuration document with a Reader field. The only persons who will access this document are :
- The administrator that will create the document
- And the server itself (the osgi code that will read the values will use a notes session opened as the server itself).
The configuration document must have a set of fields whose name correspond to the needed properties :
- oauth2.client.endpoints.authorize.url = URL of your OAuth2 Authorization Server /authorize endpoint
- oauth2.client.endpoints.authorize.accessType = When using Google Clous OAUTH2, set this value to 'offline' if you want a refresh token
- oauth2.client.endpoints.token.url = URL of your OAuth2 Authorization Server /token endpoint
- oauth2.client.endpoints.token.authMode = One of "basic"/"queryString"/"none". This is the way the secret will be passed to the token endpoint.
- "basic" : It will besent to the "Authorization Basic" header. The client_id will NOT be passed in the query string.
- "queryString" : It will be passed along the "client_id" in the query string, in the "client_secret" parameter.
- "none" : Only the "client_id" will be passed in the query string.
- oauth2.client.responseType = The OAUTH2 authorize response type. Must be compatible with the authorization code flow (or openid hybrid flow). In doubt, set it to "code+id_token".
- oauth2.client.scope = The OAUTH2 scope value. You can leave it empty, or set it to "openid" if you want to extract an id token.
- oauth2.client.clientId = Your oauth2 client application id
- oauth2.client.secret = Your oauth2 client application secret
- oauth2.client.redirectURI = URL used by the users to access your application. Must be coherent with what's configured in your OAUTH2 application.
Using the package explorer, you can create a set of HTML/JS/CSS files in the WebContent folder. Don't forget to include the NgOauth2AuthorizationCodeFlow module.
Once the plugins are deployed on your Domino Server, the database created from the ondisk project, and the configuration document filled with the right values, you can open the "index.html" page stored at the root :
http://domino/db.nsf/index.html
The code of the html page is stored in the WebContent folder, accessible using Domino Designer and the package explorer view.
When opening the page, you should be redirected to the authentication page of your authorization server. And when redirected back to the sample application, it should display the access token (only for information purpose).
You can then enter the url of a rest service protected by this access token, and call this API.
For testing purpose, if using Google Cloud, you can use the userinfo end point :
https://www.googleapis.com/oauth2/v1/userinfo?alt=json
And if using Domino Authorization Server, you can access the openid userInfo end point (don't forget to ask for the "openid profile email" scopes in the configuration document) :
http://domino/oauth2.nsf/oauth2-server/userInfo