Explore Authentication Solution for the Community Features

[dennyabrain]

We're starting off with a task to explore some ways to allow secure authentication for uli. we want to allow people to contribute slurs to our servers and it be linked to their user ID. It will be an essential thing as we build access controls and governance features.

So there's the task to do it for just Uli, but I also want us to look into some similar tattle requirements and see how we can use this cost effectively for our other apps too.

There is a fair bit of complexity involved. I'll paint  a picture of some use cases to illustrate

so lets say there is a community.uli.com that people can log into. Now setting up just this is fine. But its possible that as we are pitching to mastodon/reddit admins or a platform, we might have to create custom domains for them - platform.community.uli.com.
People who login on this domain, their data should be isolated from the users of community.uli.com

Similarly there is viralspiral.net but there could also be a classroomA.viralspiral.net we might spin up for lets say the students of classroom A (like the ones we did a workshop with), then there's a possibility that maybe we should explore a Single Sign On for tattle, where no matter what url you are on, when you click signup or register, you are led to lets say a auth.tattle.co.in, and its taken care of.

Maybe you dont need to create new user ids everytime you want to use a tattle product.

So yeah thats the long term thinking we need to adopt as we evaluate and build in this sprint. the short term goal is just to setup an authentication for uli.

Constraints :

1. Data needs to stay in our database. Managed auth providers are not an option. They also charge per user so might not be a good idea for scaling up

2. I'd prefer to deploy authentication servers via docker and have our backend servers talk to them rather than mix same authentication code in our various (js,python) backend services

[dennyabrain]

Wanted to share 2 tools that have been on my radar. ORY and Supertokens
ORY is a lot more low level and allows for custom configuration. It is headless and hence we can plug in any custom UI (ideal).
Supertokens has a self hosted option and a managed service.

[dennyabrain]

Some Requirements to consider in authentication services :

1. Allow signup and login via a UI
2. Support MFA via mobile apps (?)
3. Password recovery mechanism
4. Allow API access to enable scripts and bots to use our services.
5. Auditability of logs/security

[duggalsu]

Here is what I currently understand about Identity and Access Management (IAM) solutions

Identity and Access Management (IAM) Components

1. Identity Store
   • Only for storing the data
   • Static part of the IAM
   • Do NOT mix LDAP with relational databases in connected applications due to performance issues. Requires storing local copies of data in applications.
   • Examples - LDAP, Active Directory, Relational Database
2. Identity Management
   • Replicating data e.g. transforming data, applying policies, managing consistency, provisioning, deprovisioning
   • Integration part of the IAM
   • Examples – Evolveum MidPoint, Apache Syncope
3. Access Management
   • Handles authentication, authorization, access auditing (AAA)
   • Dynamic part of the IAM
   • Examples – Keycloak, SuperTokens, Supabase

References:

• https://docs.evolveum.com/iam/identity-management-for-dummies/
• https://docs.evolveum.com/iam/enterprise-iam/
• https://docs.evolveum.com/iam/best-practice/management-directory-access/
• https://docs.evolveum.com/iam/access-management-and-provisioning/

[duggalsu]

What to avoid when implementing an IAM solution

1. DIY IDM
   • Simple provisioning scripts bloat up quickly to handle all cases
   • Role explosion when implementing Role Based Access Control (RBAC)
   • Network communicatino issues and error handling
     Solution: Build on existing open source project
2. Everything in LDAP
   • Directory services are not built for authentication
   • LDAP is standardized, and custom fields need to be implemented and stored per application – leading to data duplication, issues with consistency when updating data and DIY approach
   • LDAP solutions do not fully adhere to standards
   • Issues with deprovisioning
   • Issues with making data available to the directory service using HR, CRM or self-registration systems (a directory service is not the primary source of data)
     Solution: Use Identity management system along with database to implement provisioning/deprovisiong. Use a separate authentication system
3. Universal Provisioning Interface
4. IDM Waterfall implementation – use iterative IDM project implementation and an open source solution to reduce technical and financial risk
5. Provisioning Interface Abuse
6. SSO First – applies when you have an existing user login database
   • Do not start with SSO if you do not have all user details across all applications and you do not know if it is financially feasible
   • Use alternatives to “true SSO” e.g. Enterprise SSO (ESSO) or “Identity Gateways”

References

• https://docs.evolveum.com/iam/antipatterns/diy-idm/
• https://docs.evolveum.com/iam/antipatterns/everything-in-ldap/
• https://docs.evolveum.com/iam/antipatterns/universal-provisioning-interface/
• https://docs.evolveum.com/iam/antipatterns/idm-big-bang/
• https://docs.evolveum.com/iam/antipatterns/provisioning-interface-abuse/
• https://docs.evolveum.com/iam/antipatterns/sso-first/

[duggalsu]

Access Management - Open Standards

1. Authorizaton
   1. OAuth 2.0 - for access delegation
2. Authentication
   1. OpenID
   2. Single sign-on (SSO) - subset of "federated identity"
   3. Multifactor Authentication (MFA)
   4. Zero Trust – Remote work without VPN (network perimeter) and internal threats
3. Authentication and Authorization
   1. OpenID Connect (OIDC)
   2. SAML 2.0

References

• https://en.wikipedia.org/wiki/OAuth#OAuth_2.0
• https://en.wikipedia.org/wiki/OpenID
• https://en.wikipedia.org/wiki/Single_sign-on
• https://en.wikipedia.org/wiki/Federated_identity
• https://en.wikipedia.org/wiki/Multi-factor_authentication
• https://en.wikipedia.org/wiki/Zero_trust_security_model
• https://www.sailpoint.com/identity-library/what-is-zero-trust/
• https://www.ory.sh/zero-trust/
• https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC)
• https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

[duggalsu]

IAM Trade-Offs to consider

1. Open Source
   1. Self-hosting option
   2. Avoid vendor lock-in - Open Standards
   3. Security self-audit
   4. Customized implementation
2. Compliance
   1. Privacy – GDPR (EU), CCPA (California, U.S.), LGPD (Brazil), PDPA (Singapore), PIPEDA (Canada)
   2. Security – ISO 27001 certification, SOC Attestation
3. Security
4. Scalability
5. Maintenance cost
6. Self-hosting
   1. Licensing - Evaluation/Production
   2. Financial feasibility
7. Cloud hosting
   1. Continuous updates
   2. Zero-downtime upgrades and migration
   3. Backwards compatibility
   4. Customer Support
   5. Privacy and Security compliance
   6. Managed Security – e.g. Encryption at rest
   7. Managed Recoverability
   8. Multi-region deployment
   9. Transfer risk – Logging and audit trail, Availability and Resilience
   10. Other features e.g. UI, organization management...
8. Cloud Integrations

References

• https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
• https://www.innominds.com/blog/open-source-tools-for-identity-and-access-management
• https://www.ory.sh/ory-network-or-self-hosting-explained-use-cases/
• https://www.ory.sh/security/

[duggalsu]

Multi-Component Solutions

1. Ory
   IAM Components
   1. Identity Store – Either in-memory or relational databases (PostgreSQL, MySQL, SQLite and CockroachDB)
   2. Identity Management – Ory Kratos, Ory Keto (Distributed RBAC)
   3. Access Management – Ory Hydra, Oathkeeper (Zero Trust)
2. Open Identity Platform
   IAM Components
   1. Identity Store – OpenDJ
   2. Identity Management - OpenIDM
   3. Access Management – OpenAM

References

• https://www.ory.sh/
• https://github.com/ory
• https://www.ory.sh/docs/ecosystem/deployment#data-storage-and-persistence
• https://www.openidentityplatform.org/
• https://github.com/OpenIdentityPlatform
• https://en.wikipedia.org/wiki/OpenIDM
• https://en.wikipedia.org/wiki/OpenDJ
• https://en.wikipedia.org/wiki/OpenAM

[duggalsu]

Potential Single-Component Solutions

Identity Store

1. Open-Source LDAP solution
2. Relational database

Identity Management

1. Apache Syncope
   • https://syncope.apache.org/
2. MidPoint Evolveum
   • https://evolveum.com/midpoint/
   • https://docs.evolveum.com/iam/
   • https://github.com/Evolveum/midpoint

Access Management

1. Keycloak
   • https://www.keycloak.org/
   • https://github.com/keycloak/keycloak
2. Central Authentication Service (CAS)
   • https://www.apereo.org/projects/cas
   • https://github.com/apereo/cas
3. FusionAuth
   • https://fusionauth.io/
   • https://github.com/fusionauth
4. Supertokens
   • https://supertokens.com/
   • https://github.com/supertokens/supertokens-core
5. Supabase
   • https://supabase.com/
   • https://github.com/supabase/supabase

Edit 1: Improved readability

[duggalsu]

Not Relevant - Other Solutions

1. Aerobase IAM Server
   https://aerobase.io/
   https://github.com/aerobase/omnibus-aerobase-server
   Issues
   • Security - Not maintained
2. Gluu
   https://www.gluu.org/
   https://github.com/GluuFederation/flex
   Issues
   • Commercially licensed
3. OpenIAM
   https://www.openiam.com/
   https://github.com/OpenIAM
   https://www.openiam.com/ce-vs-ee
   Issues
   • Could not find relevant public repos
   • Security - Community edition is one version older
4. Shibboleth
   https://www.shibboleth.net/
   https://en.wikipedia.org/wiki/Shibboleth_(software)
   Issues
   • SSO protocol and implementation typically used in academic environments
5. OpenLDAP
   https://www.openldap.org/
   Issues:
   https://docs.evolveum.com/iam/ldap-survival-guide/
   • No standard way to disable an account
6. FreeIPA
   http://www.freeipa.org/
   https://en.wikipedia.org/wiki/FreeIPA
   https://pagure.io/freeipa
   Issues
   • Identity Management System on top of Fedora Linux
7. FusionIAM
   https://fusioniam.org/
   Issues
   • Only SSO with OpenLDAP

[duggalsu]

Here are the choices to implement minimal number of solutions and get access to all IAM components. The following solutions are not considered -

1. Solutions with LDAP as the Identity Store
2. Access Management solutions with only self-hosting option
3. Access Management solutions where the public repo was unavailable

Identity Store

1. Ory
   1. PostgreSQL
   2. MySQL
   3. SQLite
   4. CockroachDB
      https://www.ory.sh/docs/ecosystem/deployment#data-storage-and-persistence
2. Supabase
   1. PostgreSQL
      https://supabase.com/docs/guides/database
3. Supertokens
   1. PostgreSQL
   2. MySQL
      https://supertokens.com/docs/emailpassword/pre-built-ui/setup/database-setup/postgresql

Identity Management

1. Ory
   https://github.com/ory#ory-open-source-servers

Access Management

1. Ory
2. Supabase
3. Supertokens

Event Monitoring and Alerting

1. Ory
   1. Prometheus endpoint (extend with Grafana dashboard integration)
      https://www.ory.sh/docs/ecosystem/deployment#prometheus
      https://www.ory.sh/docs/oathkeeper/configure-deploy#monitoring
      https://www.ory.sh/docs/kratos/concepts/security
      https://en.wikipedia.org/wiki/Prometheus_(software)
2. Supabase
   1. Built-in dashboard
   2. Only for cloud service - Prometheus endpoint (extend with Grafana dashboard integration)
      https://supabase.com/docs/guides/platform/metrics
3. Supertokens
   1. No event monitoring and alerting
   • Could not find any documents when searching for keywords: audit, report, monitor, alert, prometheus, grafana, dashboard

Options

1. Supertokens does not make sense without event monitoring
2. Supabase does not have Identity Management. Also, the Prometheus endpoint is not available in the self-hosted option.
3. Ory has all the required components. Prometheus and Grafana are widely-used DevOps tools, and make more sense than an integrated dashboard.
4. PostgreSQL makes the most sense as an Identity Store
   1. It is available as a relational database on all three IAM solutions, hence making future migration simpler. It is also the only cloud management option in solutions like Supabase and FusionAuth.
   2. It is a better option than MySQL as a secure open-source database.
      https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
      https://archlinux.org/news/mariadb-replaces-mysql-in-repositories/
      https://lists.archlinux.org/pipermail/arch-dev-public/2013-February/024478.html
      https://wiki.archlinux.org/title/PostgreSQL