Decouple OAuth Login from Resource Connections for External Service Integration

[kunal0137]

Is there an existing issue for this?

• I confirm that I have not found an existing or similar issue.

Problem (why)

Currently, all OAuth logins under UserResource are tied to authenticating users into our platform (SSO). This setup prevents users from connecting additional external accounts (e.g., Google, Gmail, Microsoft 365) for data integrations and resource access without using OAuth as their login method.
We need to enable users to connect external accounts for resource access after they are already logged into the platform, independently from the way they authenticate to SEMOSS itself.

Impact (who)

This change benefits all users who want to integrate or sync data from third-party platforms (e.g., Gmail, Google Drive), allowing greater flexibility and improved experience.
It will also unblock future integrations with other SaaS services where OAuth is required for data access but not necessarily for platform authentication.

Existing

UserResource.java
social.properties

Requirements (what)

• Add a new flag to social.properties (e.g., enable_connection) for each OAuth provider to control whether that provider is enabled for connecting resources, independently of enable_login.
• Update backend logic so that:
  • Providers with enable_login=true behave as platform SSO options as before.
  • Providers with enable_connection=true but enable_login=false are hidden from the login page, but can be added as a resource connection once the user is logged into the platform.
• Update endpoints like /auth/logins and /auth/loginsAllowed so the frontend can distinguish and separately display login options vs. resource connection options.
• Validate that changes are covered by new/updated unit tests and integration tests (including different combinations of the flags).
• Edit the user / access token objects to validate that once tokens for login providers are removed/expired, the user is logged out - even if resource login providers remain
• Document the new configuration options in supporting docs and in codebase READMEs, including migration guidelines.

[Subhadeepghosh1]

@kunal0137

As per the requirment we were required to update endpoints like /auth/logins and /auth/loginsAllowed so the frontend can distinguish and separately display login options vs. resource connection options.

previously /loginsAllowed returned providers with true/false for login. But to differentiate the login and resource connection also added enable_connection to differentiate both. Are we in correct path or better to create a separate endpoint for getting resource connections like /auth/connectionsAllowed.

This is the small sample reponse we are getting
http://localhost:9090/Monolith/api/auth/loginsAllowed
{
"keycloak": {
"enable_login": false,
"enable_connection": false
},
"cac": {
"enable_login": false,
"enable_connection": false
},

[Subhadeepghosh1]

@kunal0137

1. Added a New Flag in Configuration
   1.1) Introduced a new flag, enable_connection, for providers in social.properties.
2. Enhanced Social Data Handling
   2.1) Created a new method, getConnectionsAllowed(), in the socialData class.
   2.2) This method returns a map of providers with values as true or false based on each provider’s enable_connection flag.
3. Updated /auth/loginsAllowed Logic
   3.1) The /auth/loginsAllowed endpoint now uses the above logic to return both login options and resource connection options for each provider.
   3.2) This allows for clear distinction between login and resource connection capabilities per provider.
4. Token Validation Enhancements in User.java
   4.1) Added a new method, validateToken(), in the User.java class.
   4.2) This method checks if the token is expired.
   4.3) If the expired token is for a login provider, the user is logged out after token expiry.
   4.4) If it’s for a normal resource connection, the expired token is simply removed from accessToken.
5. Added isLoginProvider to AccessToken.java
   5.1) Introduced a new field, isLoginProvider, in the AccessToken.java class to indicate whether a given access token was issued for a login provider or a resource connection.
6. Setting isLoginProvider in Access Tokens
   6.1) In the /login/provider endpoint code, this flag is set based on a null check of the userObj:
   6.1.1) If userObj is null, it indicates a login provider, and isLoginProvider is set to true in the access token.
   6.1.2) If userObj is not null, it indicates a resource connection, and isLoginProvider is set to false.
7. Differentiated Token Handling
   7.1) This distinction allows the validateToken() method to accurately handle tokens:
   7.1.1) For login providers, it logs out users on token expiry.
   7.1.2) For resource connections, it just removes the expired token from accessToken.

[Pragya7011]

ProposedDesign.pdf

@kunal0137 : Could you please check attached updated document for login provider approach.