Before installing Ego itself, make sure the following are installed and configured on the platform of your choice (we recommend Linux):
PostgreSQL
Java Runtime Environment version 11
Your UI application hosted and available in your environment
Additionally, these prerequisite configurations must also be completed:
Configure at least one OAuth 2.0 identity provider with a Client ID
and Client Secret
(see instructions below)
For certain identity providers, make sure users' emails are publicly accessible (see instructions below)
To properly use the identity providers with Ego, OAUTH credentials must be setup with each provider you want to use, specifically a client ID and client secret.
The secret is known only to your web application and the provider's authorization server. It serves to protect your resources by only granting tokens to authorized requestors.
Each identity provider has a different process for setting up their client secrets, detailed below.
If you or your organization needs a secure solution to store, manage, and control access to all your secrets in one place, you may wish to consult with your IT department about adopting a 3rd party tool such as HashiCorp's Vault.
For full details on setting up OAUTH 2.0 for an application to work with Google, see here.
However, for your convenience, we provide summary steps here:
User Type | Description |
---|---|
Internal | If you are part of a Google Workspace, then this setting limits the app to only users within your workspace. |
External | The app will be available to any test user that has a Google account. The app starts in testing mode and is only available to users you add to the list of test users. Once testing is complete, you can verify and publish the app to production. |
NOTE: Typically, External is the recommended configuration, especially if you intend for other external users to access and use your app.
Field | Description |
---|---|
App name | Name for the app requiring consent. |
User support e-mail | For users to contact you with questions about their consent. |
Field | Description |
---|---|
Application type | Set to Web application |
Name | Enter a name for the web client |
<url>/ego-api/oauth/login/google
Where <url>
is the base URL you have deployed Ego to (e.g. this could be a specific domain name you have setup in advance, or a server address, or even your localhost
if you are running this off your laptop). For example, https://ego.overture.bio/ego-api/oauth/login/google
, https://dms.test.cancercollaboratory.org/ego-api/oauth/login/google
, http://localhost:80/ego-api/oauth/login/google
, etc.
For full details on setting up OAUTH 2.0 for an application to work with GitHub, see here.
However, for your convenience, we provide summary steps here:
Setup an account with GitHub, if you don't already have one. If you are an individual working solo with the Overture suite, you may wish to simply use a personal account. However, if you work for a larger organization or institution, they may already have a designated account which you can or should be using. Please consult your IT department if required.
Log into GitHub.
From your profile icon in the top right, go to Settings. Then from the links on the left, go to Developer Settings.
From the left, click OAuth Apps, then click New OAuth App:
Enter the Application Name - A descriptive name for your app.
Enter the Homepage URL - The URL to your app's homepage. You may simply enter the following:
In Authorized callback URIs, enter the URL where GitHub will redirect users once they have authenticated with the provider (i.e. redirect them back to Ego once logged in successfully):
<url>/ego-api/oauth/login/github
Where <url>
is the base URL you have deployed Ego to (e.g. this could be a specific domain name you have setup in advance, or a server address, or even your localhost
if you are running this off your laptop). For example, https://ego.overture.bio/ego-api/oauth/login/github
, https://dms.test.cancercollaboratory.org/ego-api/oauth/login/github
, http://localhost:80/ego-api/oauth/login/github
, etc.
NOTE: GitHub only displays the Client Secret when initially created. If you do not copy it immediately, you will not be able to see it again. If you do not copy it or lose/forget the secret later, you will need to generate a new secret and delete the old one.
You can always view the Client ID and manage (generate new, delete) the Client Secrets for your app by going back to your Developer Settings > OAuth Apps > General section in the app's lefthand navigation bar:
For full details on setting up OAUTH 2.0 for an application to work with LinkedIn, see here.
However, for your convenience, we provide summary steps here:
Field | Description |
---|---|
App name | Descriptive name for your app |
LinkedIn Page | Enter or select the LinkedIn page to be associated with your app. If you do not have one, you can create one (either real or placeholder) by clicking Create a new LinkedInPage. |
App logo | Upload a logo for your app |
Legal agreement | Read and agree to the API Terms of Use |
<url>/ego-api/oauth/login/linkedin
Where <url>
is the base URL you have deployed Ego to (e.g. this could be a specific domain name you have setup in advance, or a server address, or even your localhost
if you are running this off your laptop). For example, https://ego.overture.bio/ego-api/oauth/login/linkedin
, https://dms.test.cancercollaboratory.org/ego-api/oauth/login/linkedin
, http://localhost:80/ego-api/oauth/login/linkedin
, etc.
Review in progress
. Wait for some time and refresh the page to see if the product has been approved and added. Usually this is very quick (within a few minutes), but allow up to 24 hours for this to process. If after 24 hours you still have not been approved, please contact LinkedIn support:r_emailaddress
, r_liteprofile
:Ego makes use of the free, public ORCiD API for client applications. Hence, all steps below are described based on the use of the free, public API, and not the paid membership API. For full details on setting up OAUTH 2.0 for an application to with with ORCiD using their free, public API, see here.
However, for your convenience, we provide summary steps here:
NOTE: ORCiD requires a real URL be provided and will actually attempt to ping the site and establish its validity. If your app does not have a homepage, we recommend providing your institution or organization's homepage. However, if you do not have any of, we suggest you simply enter the Overture homepage, https://overture.bio.
<url>/ego-api/oauth/login/orcid
Where <url>
is the base URL you have deployed Ego to (e.g. this could be a specific domain name you have setup in advance, or a server address, or even your localhost
if you are running this off your laptop). For example, https://ego.overture.bio/ego-api/oauth/login/orcid
, https://dms.test.cancercollaboratory.org/ego-api/oauth/login/orcid
, http://localhost:80/ego-api/oauth/login/orcid
, etc.
NOTE: ORCiD may give a warning that "Only https redirect URIs are accepted". However, this is a warning only and you may still enter an HTTP URI as indicated above. The application will still save and the Client ID and Secret will still be generated.
Currently, as part of its authentication flow, the Ego must capture, store, and display a contact e-mail when a user logs in via their identity provider. However, some providers may allow their users to make their email addresses private and not publicly accessibly by an external service like Ego.
In scenarios where users have their emails set to private, they will NOT be able to login via Ego, and two alternatives are available:
ORCiD is the only provider that currently has this capability where the user's email can be set to private.
NOTE: Some users will want to retain their privacy and not share their e-mail publicly. As such, the Overture roadmap for Ego has a future enhancement to make this requirement configurable. However, for the current release, the two workarounds above must be used.
To make your ORCiD e-mail publicly accessible, see the instructions here, or follow these summary steps: