GSoC2022: Migrating from OpenMRS ID to a new SSO System findings

Owned by
TAYEBWA NOAH
Last updated: Mar 23, 2022
4 min read

Open-Source SSO Options


  • IdentityServer

Features

  • Authentication as a Service. Centralized login logic and workflow for all of your applications (web, native, mobile, services). ...
  • Single Sign-on / Sign-out. ...
  • Access Control for APIs. ...
  • Federation Gateway. ...
  • Focus on Customization.


  • Authelia

Features

  • Username / Password

  • Universal 2nd Factor

  • Password Reset

  • Login Regulation

  • Intuitive UI

  • One-Time Passwords

  • Per-resource authorizations

  • High Availability


  • WSO2

Features

  • Enable Easy Logins. Single sign on (SSO) 
  • Connect Everything (For instance, logging in through a social login such as Facebook or Twitter)

  • Ensure Secure Access(Multi-factor and adaptive authentication)

  • Provide Quick and User-friendly Access(Passwordless authentication)
  • Give Users Enhanced Control Over Their Data(Privacy and consent management)
  • Get a Unified View of APIs(API security)
  • Manage users and enable self-serve with ease(User management)
  • Control who has access to what(Access control)


  • KeyCloak

Features

  • Single-Sign On and Single-Sign Out for browser applications.

  • OpenID Connect support.

  • OAuth 2.0 support.

  • SAML support.

  • Identity Brokering - Authenticate with external OpenID Connect or SAML Identity Providers.

  • Social Login - Enable login with Google, GitHub, Facebook, Twitter, and other social networks.

  • User Federation - Sync users from LDAP and Active Directory servers.

  • Kerberos bridge - Automatically authenticate users that are logged-in to a Kerberos server.

  • Admin Console for central management of users, roles, role mappings, clients and configuration.

  • Account Management console that allows users to centrally manage their account.

  • Theme support - Customize all user facing pages to integrate with your applications and branding.

  • Two-factor Authentication - Support for TOTP/HOTP via Google Authenticator or FreeOTP.

  • Login flows - optional user self-registration, recover password, verify email, require password update, etc.

  • Session management - Admins and users themselves can view and manage user sessions.

  • Token mappers - Map user attributes, roles, etc. how you want into tokens and statements.

  • Not-before revocation policies per realm, application and user.

  • CORS support - Client adapters have built-in support for CORS.

  • Service Provider Interfaces (SPI) - A number of SPIs to enable customizing various aspects of the server. Authentication flows, user federation providers, protocol mappers and many more.

  • Client adapters for JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring, etc.

  • Supports any platform/language that has an OpenID Connect Relying Party library or SAML 2.0 Service Provider library


My new findings and why key cloak, wso2, Authelia, CAS, Identity server may not help us

We had decided to use keycloak with miniorange
If we are to use jira and confluence cloud instances, we need to use a tool called atlassian access not miniorange. atlassian access has no intergrations we Keycloak so I think for that case we are left with no option apart from shifting from keycloak to a different identity provider.  The few identity providers that are intergrated with atlassian access are

1) Okta

2) OneLogin

3) Azure AD

4) Google Cloud

5) PingFederate


For now, the above are the only Identity providers that are supported by atlassian access and this information can be found here https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/#Userprovisioning-Supportedidentityproviders.
For now I think we may be prompted to pick one among the 5 identity providers.
Still not so sure on how to get a jira and confluence cloud server for myself to test all this, but am grateful if anyone can help we get one up for testing before the actual project begins.


New resolution as advised my Cintia Del Rio 

Our goal is to generalise Atlassian domain verification so that people can signup and login with various domains not a single verified domain to Atlassian access.

By default, Atlassian access supports SAML single sign on, and SCIM provisioning

How SAML single sign on works with Atlassian access

Atlassian Access for enterprises and full control over access of Atlassian Jira Cloud application using a single set of login credentials for secure access using miniOrange SSO solution. Single Sign-on (SSO) into your Atlassian Jira Cloud Account with any of your existing Identity Provider (IDP) or AD credentials for enhanced security https://www.miniorange.com/atlassian-jira-cloud-single-sign-on-sso#stepc. 

The minorange plugin supports oauth but works the same as SAML Single sign on which supports Atlassian domain verification as a prerequisite for Atlassian access. This is according to the Atlassian documentation https://www.miniorange.com/atlassian-jira-cloud-single-sign-on-sso#stepc. This cannot help us achieve our goal which is  to generalise Atlassian domain verification so that people can signup and login with various domains not a single verified domain to Atlassian access.


How SCIM provisioning works with Atlassian access

Atlassian supports user provisioning using the System for Cross-domain Identity Management (SCIM), and this feature uses the SCIM 2.0 version of the protocol.

User provisioning integrates an external user directory with your Atlassian organization. This integration allows you to automatically update the users and groups in your Atlassian organization when you make updates in your identity provider. For example, with user provisioning, you can create, link, and deactivate managed Atlassian user accounts from your identity provider.

"When you set up user provisioning, you create a directory for your users. All users and groups in your identity provider from your verified domain(s) or from outside your verified domain(s) sync to your organization's directory" and this is what we want. You can read the full documentation https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/.


How to configure SCIM provisioning Using Keycloak as an identity provider

We can configure Keycloak to support SCIM provising using https://github.com/Captain-P-Goldfish/scim-for-keycloak

Currently, following the installation guide in this repository https://github.com/Captain-P-Goldfish/scim-for-keycloak using README.md there are build failures. You can refer to the pull request I made here https://github.com/Captain-P-Goldfish/scim-for-keycloak/pull/50 to solve the current build failures that's if the pull request is not yet merged it yet. After the installation, your keycloak them should have the SCIM theme