Security

While selecting the tools which are used in CAS, major emphasis has been set on security. Architectural components and technologies which are used are chosen mostly because of the advantages they provide compared to the alternatives.

The infrastructure of the CAS application server is designed to be hidden. This is achieved by using a HAProxy web-server for reverse proxying incoming HTTP requests to the server for proper applications. Having a reverse proxy protects the CAS application server from probing and attacks. HAProxy secures the CAS application server with TLS and the CAS backend allows incoming connections only from secured locations. Securing connections between CAS application servers and OAuth2 client web-systems offers three primary services which help ensure the safety and security of the data exchanged:

• Authentication enables each party to identify the other party’s identity.
• Data is encrypted while being transmitted between the user agent and the server in order to prevent it from being read and interpreted by unauthorized parties.
• TLS ensures that between encrypting, transmitting, and decrypting the data no information is lost, damaged, tampered with, or falsified.

The language for developing the CAS backend that handles all business logic is Java Spring Boot 2.0. This technology was chosen because it is the newest stable version of the widely used and tested framework for developing enterprise applications. The work-flow used for granting authorization comes from the OAuth2 framework which is one of the most used authorization protocols in the industry. In OAuth2 the user is given access to a resource (the resource of the OAuth2 client web-system) with access tokens. The OAuth2 specification does not define what a token is. In CAS JSON Web Tokens are used.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. In CAS, JWT access_tokens are signed using public/private key pairs. Signed tokens verify the integrity of the claims contained within it. As tokens are signed using public/private key pairs, the signature on the token also certifies that only the party holding the private key (CAS backend) is the one that signed it.

As public/private key pairs are generated by the CAS backend, the system provides an endpoint for CAS Oauth2 clients to request the public key which they must use to verify the signature in the JWT access_token. The following subtopic explains how OAuth2 clients can request a public key from the CAS backend.

The image here describes how a CAS OAuth2 client obtains a public key from CAS. OAuth2 clients have to make a GET request to the following endpoint:

https://eid.eregistrations.org/cback/v1.0/user/publicKeyAsPem

Upon receiving a request to this endpoint CAS returns the public key as a binary file which the client needs to store. Example of the returned result:

-----BEGIN RSA PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqIyJofYpU+30APq/9wWr
BlEkWM4uWNFBL2C/WMDmFneZNyV/PqIwKyjz/ypDhKKxLOLrPLnhondXkPVqE4Qu
HLYrsht/++bXdu+AiwFedeNbEAEw2rFbj6x2QXAhNcV/EKoIO3Pp8JX9Sfsm7rr6
PVquF5ZutilDINkA1sShmnaFdBuifWzq4F2zoQp5W46Y7yannzNRHwhPAk9TmicV
J+q0McjeGTKJ86HhDzNG+q+3aZ5weiLV3dFk7xLnHprGNrI5HkiXl/XeGR9/f8vA
3GAqqjBF64PUdDehuuBOurH3gjh1mSkqh+CKLRjThQvdwlqvDLwA264V4e2rsFFk
iwIDAQAB
-----END RSA PUBLIC KEY-----

When using a returned public key, the signatures on access_tokens (received when users are entering OAuth2 client web-systems) must be verified.

Requesting a public key from CAS is not a process that has to be done only once. Every time the CAS backend system is restarted, a new pair of public and private keys are generated. Therefore, after CAS restarts, the new access_tokens which are signed with a new private key are no longer valid when checked against the public key from the previous pair. This is why it is important, should an access_tokens signature verification fail, that the CAS OAuth2 client determine whether CAS has generated a new pair of private and public keys. To check, the OAuth2 client web-system must make another GET request to the endpoint that then returns a public key and determines whether it differs from the one that was previously stored. Most likely the public key is different and the client’s system must store the new public key and verify the access_tokens signature against the new public key. This time as the public key is from the same pair as the private key which was used to sign the token, the signature verification is successful and the client can decode it to read user data from it. In the unlikely event that signature verification still fails, the CAS OAuth2 client’s system must never give the user access to the system since the access_token was not signed by CAS.