lizardsystem/lizard-auth-server

Django backend for the old SSO server

Lizard-auth-server README

Lizard auth server was originally build upon django-simple-sso.

It is installed as https://sso.lizard.net, see https://github.com/nens/sso/

Workflow

The workflow follows the django simple sso workflow.

Updating translations

Go to the lizard_auth_server subdirectory:

$ cd lizard_auth_server
$ ../python3 manage.py makemessages --all

Update the translations (for Dutch), for instance with "poedit". Then compile the new translations:

$ ../python3 manage.py compilemessages

Note: this also fetches af/vi/zh, but we don't translate into those languages currently. They're ignored in the .gitignore file.

Development with docker

The short version:

$ docker-compose build
$ docker-compose run web make install
$ docker-compose run web python3 manage.py migrate
$ docker-compose up

The site will now run on http://localhost:5000

Running the tests:

$ docker-compose run web python3 manage.py test

A quick way to run isort and black:

$ docker-compose run web python3 manage.py migrate

Note that the makefile makes sure the requirements.txt is updated with "pip-compile" when setup.py or requirements.in changes. You can also run it by hand.

A requirements.txt file isn't really needed, as it is a library. It was added to help keep track of versions when updating.

Grabbing production database

Dump:

$ pg_dump -f sso.dump -F c \
  -h DATABASESERVER -U sso \
  -N topology -T spatial_ref_sys sso

Restore:

$ pg_restore --no-owner --clean --dbname sso --username buildout --host db

lizard-auth-server's Issues

Connect/migrate SSO to AWS

I stumbled upon this page: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-import-using-lambda.html . This might me an alternative to #85

In short, it works like this:

1. User logs in in AWS Cognito
2. AWS Cognito checks the AWS user pool
3. If user does not exist, AWS Cognito calls a "migration Lambda function" with username and password as arguments
4. The lambda function checks username and password with our SSO and returns {finalUserStatus = "CONFIRMED"} along with some user attributes
5. AWS Cognito creates the user profile
6. AWS Cognito responds with tokens etc.

After this works, we can start moving the SSO out of the loop, app by app. This would enable Authorization Code Flow (fetching access tokens).

No unittests are available.

There are no unittests for the SSO server.

URL voor na het activeren door kunnen geven

Na het activeren van je account krijg je een linkje "ga naar het portaal dat jouw account heeft aangevraagd".

Als een server meerdere hostnames heeft zou het lekker zijn als de hostname die daar staat instelbaar is. Default is het de visit_url van de Portal.

Create an API endpoint for the AWS migration trigger

We need a new endpoint that checks username/password against the local database only. (so not the AD)

In the response should be some details about the user (email, name) so that the complete profile can be migrated to AWS.

Also we want to record the migration in the SSO with a flag is_migrated on the model.

Further reading about the migration trigger:

https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-migrate-user.html#cognito-user-pools-lambda-trigger-syntax-user-migration

• there is also a "forget password" flow (then only the username is sent)

UserProfile.all_organisation_roles(self, portal) should return distinct values

UserProfile.all_organisation_roles(self, portal) does not return unique values. In the end, this results in many logically identical records in table lizard_auth_client_userorganisationrole, because it is lacking a unique index on (user_id, organisation_id, role_id).

Django updaten naar 2.2 LTS

Django = 1.9.X wordt sinds april 2017 niet meer gesupport.

Nb. Mssn idee om dit direct ook in kaart te brengen voor alle projecten? Dan kunnen we lijstje maken welke allemaal nog moeten en even verdelen wie welke gaat updaten ;)

Show user/pass requirements in the UI

The username ("no spaces") and the password ("longer than x characters") have some requirements. They aren't shown in the form, though. You only see them after you've submitted a wrong one.

'allowed_domain' is required

The new 'allowed_domain' pattern is required. Existing sites don't have them yet, so saving them fails.

Is this really required? If you don't use the 'next' parameter, it shouldn't be necessary, right?

And the term "pattern" suggests wildcards or regexes. Which one is it? Provide an example in the form.

Add N&S AD as identity provider in AWS Cognito

We think this is already possible (over SAML) because Google also makes use of our AD.

Some reading:
https://aws.amazon.com/blogs/mobile/building-adfs-federation-for-your-web-app-using-amazon-cognito-user-pools/

Users can change their own email address without verification

We are going to connect SSO users to local app-users through their email address.
For that, it is important that the email address is really really from the user.

Via the SSO users can just change their email address into anything. That is a security issue.
Quick fix is disabling the editing of email address in the edit_profile view.

Better fix is adding an "email_verified" field and sending confirmation emails if someone changes his/her email address.

Configure the AWS migration trigger

For the user migration from SSO to AWS Cognito user pool we are going to user a "migration trigger" lambda function.

See:
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-migrate-user.html#cognito-user-pools-lambda-trigger-syntax-user-migration

This function should be written based on the endpoint developed in #96

Kort overleggen met Remco over aanpak rechten in groepen

Ik heb nog een openstaand pull request dat volgens mij nuttig is, alleen zit dat verwoven met een move naar Django 1.7 (maar 1.6 krijgt toch al geen security updates meer...)

En ik denk dat een paar dingen uit het model invloed kunnen hebben op de implementatie van de nieuwe pagina's.

Start cursor in user field on login screen

Because otherwise my autotyper can't find the field. And besides, that's where it blinks on all of the better login screens around the web.

Investigate timeouts on the migrate_user endpoint

The call to the migrate_user endpoint takes more than 1 second sometimes.

This should be investigated.

I suspect the SQL query to be the culprit. We can probably add a weird index to optimize this query. On production the table is larger so this issue becomes larger too.

It's possible to log on with an inactive account

If I disable an account at the SSO, I can still log on into NXT.

User management

Currently, user management is done via

1. Django admins in all client apps
2. Lizard user management
3. 3Di user management (=lizard-auth-client)

As users will migrate away, we need to decide how to change this.

Some thoughts are here:
https://docs.google.com/document/d/1SnlCkQUhGcnqqJcglle33fAUpcKn1BIyIhRpfRJliYs/edit

The amount of work depends on the chosen solution. Functional requirements will be formulated by Joeri

Make the SSO OIDC compliant

We need to add our SSO as an identity provider to our AWS Cognito account. For this it is easiest to use OpenID Connect, according to @reinout this has been implemented already only it is switched off currently.

To configure it in AWS Cognito:
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html

User migration should not work for LDAP users

@WolfSchouten

Disable the "edit_profile" view

Note that the lizard client links to the edit_profile view. It needs a "temporarily disabled" page or something.

Reroute SSO login to AWS

We need to replace all local login stuff in the SSO with a call to AWS. There is one exception: the AWS callback endpoint (#96) should still look in the local database. Also, the AD login should remain working as is.

The call to AWS should use the "USER_PASSWORD_AUTH" login flow. This should be initiated via the "AdminInitiateAuth" endpoint (you also have "InitiateAuth", but that is meant for frontend calls such as from a native javascript app)

See:
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminInitiateAuth.html

Probably best to use boto3 for handling the AWS-specific request signing. We also need a developer account to enable this. SSO should be registered as a separate client in aws.

SSO authentication does not work for users that were created in Cognito

See Sentry https://sentry.io/organizations/nens/issues/2222720310

This happens when a user account exists in Cognito, but not in the SSO.

If someone authenticates in the SSO, the authentication is done in Cognito. So far so good.

But, because an SSO user does not exist yet (and we need it for the SSO user session) a new user is created in the SSO

lizard-auth-server/lizard_auth_server/backends.py

Line 69 in 3824edf

user, created = CognitoUser.user_class.objects.get_or_create(username=username)

But this isn't allowed because the user exists in Cognito already

lizard-auth-server/lizard_auth_server/signal_handlers.py

Line 20 in 3824edf

cognito_user = CognitoUser.from_username(instance.username)