Create new authentication/authorization system #67

Open
opened 2023-09-02 20:57:41 +02:00 by h7x4 · 3 comments
h7x4 commented 2023-09-02 20:57:41 +02:00 (Migrated from github.com)

Currently Balduzius serves as KDC master (Swedish kerberos lmao, not the MIT one, ITK has good docs). In addition, Spikkjeposche runs SimpleSAML for auth services for web.

We have not touched these systems in a long while, and with moving the servers and most services rather using either LDAP or OIDC for auth these days, we really need a need setup.

Mandatory features

  • Authenticate web services like nettsiden, gitea, mediawiki, etc...
  • Authenticate SSH login to machines via PAM

Nice to have features

  • Authorize access to different kinds of resources using groups, like present in LDAP or OAuth2.
  • Reduce amount of duplicate state, absolute single source of truth is probably impossible but strive to achieve this. Especially for things like usernames, UIDs and GIDs.
  • Users should be able to change their own password.
Currently [Balduzius](https://www.pvv.ntnu.no/pvv/Maskiner/balduzius) serves as KDC master ([Swedish kerberos lmao, not the MIT one](https://manpages.debian.org/testing/heimdal-docs/krb5.conf.5heimdal.en.html), ITK has [good docs](https://itk.samfundet.no/dok/Kerberos)). In addition, [Spikkjeposche](https://www.pvv.ntnu.no/pvv/Maskiner/Spikkjeposche) runs [SimpleSAML](https://simplesamlphp.org/) for auth services for web. We have not touched these systems in a long while, and with moving the servers and most services rather using either LDAP or OIDC for auth these days, we really need a need setup. ### Mandatory features - Authenticate web services like nettsiden, gitea, mediawiki, etc... - Authenticate SSH login to machines via PAM ### Nice to have features - Authorize access to different kinds of resources using groups, like present in LDAP or OAuth2. - Reduce amount of duplicate state, absolute single source of truth is probably impossible but strive to achieve this. Especially for things like usernames, UIDs and GIDs. - Users should be able to change their own password.
felixalbrigtsen commented 2023-09-03 02:51:07 +02:00 (Migrated from github.com)

We have a few options for this one;

Keep our existing setup

  • This involves keeping Balduzius with heimdal kerberos, and reconfiguring SimpleSamlPHP on a new host.
  • This will not give any support for LDAP or OAuth2

This is the "simplest", but is quite problematic as we need OAuth2 and LDAP to integrate with new web services and allow user login on NixOS.
This makes it not viable in the long run.

Keep using kerberos, add keycloak and LDAP

  • Keycloak is a huge blob of java that's pretty good at its job; SSO
  • It's an open source project supported by RedHat, active for many years.
  • Keycloak will provide Oauth2/OIDC, and we will need OpenLDAP and a kerberos server in addition
  • Web services will auth with Keycloak, and PAM / local machines will auth with LDAP+Krb5

The biggest disadvantage of this system is that it can be quite a lot of work to configure and maintain all these different services, separating and combining them in the right way.
OpenLDAP and Keycloak are both in nixpkgs, so running them should be very possible.
The end result will expose both LDAP and Oauth2, but with many moving parts that depend on each other.
Key words: Old, stable, clunky, predictable

Use Kanidm

  • Kanidm A simple, secure and fast identity management platform , written in rust
  • This is quite new, just moved into beta
  • Kanidm implements a minimal LDAP and a minimal Oauth2 / OIDC
  • It does not expose kerberos, but provides a custom PAM module to facilitate local authentication

This is a young project still in beta, but most of the core features seem to be stable.
This will probably be the simplest system to manage, as a single program will manage all our authentication and authorization.

It will however not be as "standard" as the above solution. Local auth with PAM will require a custom module made by Kanidm, and not all LDAP features are supported.

My suggested plan:

  • Configure a new nixos machine with full disk encryption and a Kanidm server
  • Make some demo users
  • Try to authenticate a few services with kanidm; Like gitea and mediawiki
  • Test the pam module and LDAP login on a few different systems; Debian, FreeBSD and NixOS needs to be able to auth users
  • Find or write some tooling for our most important operations:
    • Import / Migrate users from our existiing salt+kerberos setup (usernames, UIDs, etc)
    • Create new users from NTNU usernames
    • Manage groups / teams

When these things are confirmed working, we can start migrating users and designing how we organize groups, ids and similar.

We have a few options for this one; ## Keep our existing setup - This involves keeping Balduzius with heimdal kerberos, and reconfiguring SimpleSamlPHP on a new host. - This will not give any support for LDAP or OAuth2 This is the "simplest", but is quite problematic as we need OAuth2 and LDAP to integrate with new web services and allow user login on NixOS. This makes it not viable in the long run. ## Keep using kerberos, add keycloak and LDAP - Keycloak is a huge blob of java that's pretty good at its job; SSO - It's an open source project supported by RedHat, active for many years. - Keycloak will provide Oauth2/OIDC, and we will need OpenLDAP and a kerberos server in addition - Web services will auth with Keycloak, and PAM / local machines will auth with LDAP+Krb5 The biggest disadvantage of this system is that it can be quite a lot of work to configure and maintain all these different services, separating and combining them in the right way. OpenLDAP and Keycloak are both in nixpkgs, so running them should be very possible. The end result will expose both LDAP and Oauth2, but with many moving parts that depend on each other. Key words: Old, stable, clunky, predictable ## Use Kanidm - [Kanidm](https://github.com/kanidm/kanidm) A simple, secure and fast identity management platform , written in rust - This is quite new, just moved into beta - Kanidm implements a minimal LDAP and a minimal Oauth2 / OIDC - It does not expose kerberos, but provides a custom PAM module to facilitate local authentication This is a young project still in beta, but most of the core features seem to be stable. This will probably be the simplest system to manage, as a single program will manage all our authentication and authorization. It will however not be as "standard" as the above solution. Local auth with PAM will require a custom module made by Kanidm, and not all LDAP features are supported. # My suggested plan: - Configure a new nixos machine with full disk encryption and a Kanidm server - Make some demo users - Try to authenticate a few services with kanidm; Like gitea and mediawiki - Test the pam module and LDAP login on a few different systems; Debian, FreeBSD and NixOS needs to be able to auth users - Find or write some tooling for our most important operations: - Import / Migrate users from our existiing salt+kerberos setup (usernames, UIDs, etc) - Create new users from NTNU usernames - Manage groups / teams When these things are confirmed working, we can start migrating users and designing how we organize groups, ids and similar.
felixalbrigtsen commented 2023-09-03 03:31:17 +02:00 (Migrated from github.com)

There are also many alternatives to OpenLDAP, and some who combine LDAP and kerberos into single services.

These larger/combined services include

  • Apache DS - All-in-one solution from Apache
  • FreeIPA - Clunky RHEL-only solution, not fun to manage
  • Microsoft Active Directory (haha, no)

and other smaller LDAP servers like

I don't think any of these will be better suited to our needs than the original suggestions above, but they are worth mentioning/researching.

There are also many alternatives to OpenLDAP, and some who combine LDAP and kerberos into single services. These larger/combined services include - [Apache DS](https://directory.apache.org/apacheds/) - All-in-one solution from Apache - [FreeIPA](https://www.freeipa.org/) - Clunky RHEL-only solution, not fun to manage - Microsoft Active Directory (haha, no) and other smaller LDAP servers like - [389DS](https://www.port389.org/) - [LLDAP](https://github.com/lldap/lldap) I don't think any of these will be better suited to our needs than the original suggestions above, but they are worth mentioning/researching.
dali99 commented 2023-09-03 17:29:49 +02:00 (Migrated from github.com)

I support trying kanidm to see what the workflow would look like

I support _trying_ kanidm to see what the workflow would look like
oysteikt self-assigned this 2024-08-03 22:10:39 +02:00
oysteikt added this to the Kanban project 2024-08-03 22:52:19 +02:00
oysteikt removed this from the The big serverroom purge milestone 2024-08-22 15:27:54 +02:00
oysteikt added this to the Authentication Next Gen milestone 2024-08-22 15:27:58 +02:00
oysteikt added the
security
nixos
big
labels 2024-08-22 23:36:55 +02:00
danio added the
disputed
label 2024-08-31 12:22:16 +02:00
Sign in to join this conversation.
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Drift/issues#67
No description provided.