Introduction
This project is available for the Special season as a variation of the project explored during the course normal season.
It explores similar concepts with some variations, which are described in this document.
Project Description
The work consists on developing an IdP supporting services with different criticalities, and applying multi-factor authentication methods, in a dynamic manner according to the service requirements and user perceived risk. The IdP shall support a flow based on the Security Assertion Markup Language (SAML).
It will also aim at addressing the issue of MFA fadigue, by tailoring the authentication process in order to keep the security level, while not burdening the user too much. For this project, students should consider a risk score, where every 10 points adds another authentication method, up to four (Password + 3 others).
The IdP shall support the definition of services, consisting of web applications that use the IdP to authenticate their users. The web applications must be registered into an IdP using some metadata, containing:
- The public key to use for validating the Web Application SAML Request, and to encrypt the SAML Response.
- The identity attributes to be provided by the IdP.
- The Penalty value to consider when a suspect action or change takes place.
- The Minimum number of authentication methods always requested (>=1).
- The URL to use by the IdP to send the SAML Response.
As an example, applications may state a small penalty (1) or a large penalty (10), making the IdP requiring a dynamic number of authentication methods. The following authentication methods should be considered:
- Password;
- TOTP using an offline application;
- HOTP using an email, instant message or other similar method;
- A hardware related method such as a USB key, a Smartcard or a Passkey.
A basic service must be implemented to exercise the IdP. The service must consider multiple roles for their users, appling some form of access control with principles from both Bell–LaPadula and Biba. A simple message billboard, or document store, mapped to a Role based structure may suite this purpose.
Project development and delivery
This project is to be implemented by $1$ student. The project can be coded in any language but must use a SAML2 workflow, in line with the SAML2 specification: https://wiki.oasis-open.org/security/FrontPage#SAML_V2.0_Standard. Strict compliance with the SAML2 specification is not required.
Development should be done in a Github repository, and the professors should be added as team members.
Delivery should consist of a ZIP containing the repository clone, and a PDF report. The PDF report must contain a link to the original repository in Github.
The report should describe the architecture, risk model, and system implemented. Such description must include the data structures stored, the structure of the messages exchanged and the message flows, the interfaces used and their parameters, some relevant implementation details (not complete copies of the code, as they are in the repository), the MFA and risk tracking approach, and the results achieved (screenshots and demonstration of the different processes).
The results should demonstrate the effectiveness of the system to correctly authenticate users under different risk situations.
The project shall be delivered until September 11, 23.59 through Microsoft Teams.
Evaluation
This project will be evaluated as follows:
- Written report describing the solutions: 20%
- Correctness and demonstration of an implementation with:
- Example Web Application: 10%
- IdP with adequate user attributes: 10%
- 3 MFA methods: 20%
- A risk based approach with scalable authentication: 10%
- Support for a SAML aligned processes between services and the IdP: 20%
- Role based information flow control: 10%
References
- hhttps://wiki.oasis-open.org/security/FrontPage#SAML_V2.0_Standard
- https://github.com/IdentityPython/pysaml2