The CORE service is exposed to other services through a REST API. LabraDoor offers a generated client that can connect to this REST API. LabraDoor also takes care of the needed security protocols that are in place to connect to CORE.
All that is needed to configure the API client is to provide the following information in your `application.yml`:
url:http://localhost:8082# The URL where CORE lives
apiKey:test-key# The name/key of your API key with CORE, usually a UUID
apiSecret:njkdabnjuasdkjbjbdaioasd# The secret of your API key with CORE
A couple security protocols are implemented and enabled by LabraDoor. These were added to a library because we found that we had to implement the same protocols multiple times over similar projects. The protocols are based on the fact that authentication is usually provided by an external service.
TU Delft has a single authentication service (commonly referred to as an IdP, for Identity Provider) that is used by all TU Delft services to identify users.
For instance, when logging into Brightspace, the user is redirected to Gatekeeper, the TU Delft Identity Provider, and asked to login there.
LabraDoor implements the connection to any Gatekeeper-like service and gets the information about the user as granted by Gatekeeper out of the response from Gatekeeper.
<b>WARNING: DO NOT USE THIS IN PRODUCTION EVER</b>
For testing purposes, LabraDoor also provides an in-memory implementation of an external IdP.
This means that, when testing a Spring application using LabraDoor, one can provide LabraDoor with a few users and simulate a login page through LabraDoor.
To implement and use the security protocols provided by LabraDoor, a couple classes/interfaces need to be extended/implemented and exposed to Spring by the Spring application using LabraDoor.
Additionally, some configurations are required to properly set things up and for in-memory, a custom login page needs to be served.
The following configurations are required to be added to `application.yml` depending on your needs for your chosen identity provider:
# As explained in the CORE API sections:
# General settings of the SSO Provider to use and login and logout path.
type:in-memory# The SSO provider to use, either 'in-memory' or 'saml'
login-path:/login-custom# The logout page path, defaults to /logout
logout-path:/logout-custom# The login page path, defaults to /login
# Only use the following for in-memory.
saved-request-aware:true# Whether the login should redirect to the last attempted page
success-url:/# The URL that logins get redirected to if none is cached or saved-request-aware is turned off
# For the SAML security configurations, we refer to documentation here:
add("Student 1",1,STUDENT);// Creates a new student user with username `student1`
add("Teacher 1",2,TEACHER);// Creates a new teacher user with username `teacher1`
#### Login page for in-memory
Finally, when using the in-memory provider, currently we need to serve some login page that submits a username and password to the server. For this the implementing Spring application needs to serve a page on `/login`.
The provided HTML must contain a form that submits to `/perform-login` with a POST. The following HTML can accomplish this goal: