Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
P
Project -- Web SSO with KinD
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Help
Help
Support
GitLab documentation
Compare GitLab plans
GitLab community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
LSDS
Teaching
Bachelor
Cloud-and-Deployment
Project -- Web SSO with KinD
Commits
cee2baf4
Unverified
Commit
cee2baf4
authored
7 months ago
by
Marco Emilio "sphakka" Poleggi
Browse files
Options
Downloads
Patches
Plain Diff
README work in progress...
Signed-off-by:
Marco Emilio "sphakka" Poleggi
<
marcoep@ieee.org
>
parent
6b223d24
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
README.md
+11
-12
11 additions, 12 deletions
README.md
with
11 additions
and
12 deletions
README.md
+
11
−
12
View file @
cee2baf4
...
@@ -23,10 +23,10 @@ S3 storage for the enrollment and session data.
...
@@ -23,10 +23,10 @@ S3 storage for the enrollment and session data.
The system architecture is composed of 3 tiers:
The system architecture is composed of 3 tiers:
1.
The
**front-end**
that provides a log-in Web GUI (languages: HTML5, JS)
1.
The
**front-end**
that provides a log-in Web GUI (languages: HTML5, JS)
and sends incoming authentication requests to the back-end.
and sends incoming authentication requests to the back-end.
2.
The
**back-end**
(languages: Python
,
Flask
/Gunicorn/???
) that receives
2.
The
**back-end**
(languages: Python
/
Flask) that receives
and handle authentication requests from the front-end. All the session
and handle
s
authentication requests from the front-end. All the session
logic is implemented here in a CRUD-like fashion: session objects are
logic is implemented here in a CRUD-like fashion: session objects are
stored in a S3-compatible storage.
stored in a
n
S3-compatible storage.
3.
The
**storage**
tier is a standard S3-like object storage which can be
3.
The
**storage**
tier is a standard S3-like object storage which can be
accessed only by the back-end.
accessed only by the back-end.
...
@@ -59,7 +59,7 @@ Buttons: 4, named as the routes above.
...
@@ -59,7 +59,7 @@ Buttons: 4, named as the routes above.
### Storage
### Storage
:construction: S3-like object storage composed of
2
buckets: one for
:construction: S3-like object storage composed of
1
buckets
with two directories
: one for
*enrollment*
data, one for
*session*
data.
*enrollment*
data, one for
*session*
data.
...
@@ -119,9 +119,9 @@ An enrolled user authenticates to the system with the `login` function:
...
@@ -119,9 +119,9 @@ An enrolled user authenticates to the system with the `login` function:
-
IF user does not exists THEN returns 'KO:NO_SUCH_USER'
-
IF user does not exists THEN returns 'KO:NO_SUCH_USER'
-
ELSE verifies sessions:
-
ELSE verifies sessions:
1.
IF an active session exists THEN returns 'OK'
1.
IF an active session exists THEN returns 'OK'
2.
ELSE returns 'NEED_
*
PASSWORD
*
'.
2.
ELSE returns 'NEED_PASSWORD'.
4.
**Front-end**
receives first response from the back-end:
4.
**Front-end**
receives first response from the back-end:
-
IF response == 'NEED_
*
PASSWORD
*
' THEN
-
IF response == 'NEED_PASSWORD' THEN
1.
Prompts the user for their
*password*
.
1.
Prompts the user for their
*password*
.
2.
**User**
provides
*password*
.
2.
**User**
provides
*password*
.
3.
**Front-end**
sends
*e-mail*
and
*password*
to the back-end.
3.
**Front-end**
sends
*e-mail*
and
*password*
to the back-end.
...
@@ -157,17 +157,16 @@ The infrastructure is entirely hosted by SwitchEngines (OpenStack cloud) and
...
@@ -157,17 +157,16 @@ The infrastructure is entirely hosted by SwitchEngines (OpenStack cloud) and
is composed of
is composed of
*
A single VM featuring:
*
A single VM featuring:
*
A Debian 12 Bookworm OS image
*
Source image: A Debian 12 Bookworm
*
2 vCPUs, 4GB RAM, 40GB root disk
*
Flavor: 2 vCPUs, 4GB RAM, 40GB root disk -- no extra volume needed
*
:question: No extra volume?
*
A KinD installation
*
A KinD installation
*
Two
S3 bucket
s
.
*
One
S3 bucket.
The infrastructure (computing instance + S3 storage) shall be provisioned via
The infrastructure (computing instance + S3 storage) shall be provisioned via
**Terraform**
.
**Terraform**
.
:bulb: References:
:bulb: References:
*
S3
: https://
github.com/yomovh/tf-at-ovhcloud
*
Terraform
: https://
registry.terraform.io/providers/hashicorp/aws/latest/docs
*
:question: what else?
*
:question: what else?
...
@@ -194,7 +193,7 @@ You shall:
...
@@ -194,7 +193,7 @@ You shall:
**
(TO-DO: We should provide instructions. Build on the student's
**
(TO-DO: We should provide instructions. Build on the student's
workstation?)
**
.
workstation?)
**
.
3.
Complete the
`Terraform/main.tf`
recipe to handle the provisioning of the S3 storage
3.
Complete the
`Terraform/main.tf`
recipe to handle the provisioning of the S3 storage
bucket
s
.
bucket.
4.
Complete the
`Ansible/deploy.yml`
playbook to handle:
4.
Complete the
`Ansible/deploy.yml`
playbook to handle:
-
exposure of the application portal IP (e.g., load-balancer IP) to the
-
exposure of the application portal IP (e.g., load-balancer IP) to the
Internet via
`socat`
or other mechanism of your choice;
Internet via
`socat`
or other mechanism of your choice;
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment