Question-
Is having a dedicated user per integration a personal choice or it is a good practice?
Background
We have about 5 different Integrations with Salesforce. Each integration serves different purpose and needs. e.g. one is a bidirectional sync, other is a 1 directional sync from external system to SF, yet another is a 1 directional sync from SF to external system.
Currently we have a dedicated Integration User for each Integration.
The reason as I understand is that, each integration user has different permissions, and also for whatever reason if we have problems with one user account, we do not want all the integrations to be affected. Having a dedicated user per integration also would allow us to better debug and mitigate issues.
Can someone suggest ideas as to how to decide - if it is better to create a new integration user or use the same user for more than one integrations.
I would say that the strongest arguments to reuse the same user for multiple integrations are:
User licenses are expensive and some organizations don't have many unused licenses.
It is easier to maintain a single user with a single profile.
However, I prefer having separate users per integration for some of the same reasons you already mentioned:
Security: each integration user has access only to what it needs and nothing else.
Ability to better isolate and debug issues that arise.
Personally, I like the approach of having a stripped-down integration Profile assigned to all my integration users and assigning permissions via Permission Sets; it makes thing easier to manage.
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
I know design is subjective. But I wanted to know if this is a good idea?
Suppose I implement OpenID connect in my application. I support sign in through multiple platforms. But now, suppose I need to maintain a database of my users for authorisation of resources on my server; or let's just say I need to store user preferences.
Is it a good idea to maintain a user's table and push data into it every time a user signs in using OpenID, or using my sign up/sign in API, using email ID of the user as the primary key (since that doesn't change) provided by OpenID?
What are some good ways to combine the two? What are some pros and cons of this?
What are the best ways to support authorisation (of resources on my server) along with authentication using OpenID/oAuth?
It is a really good question and not covered well in many places.
TRACKING USERS
In terms of sign in via multiple platforms a common pattern is to use the same authorization server for all types of login and 'federate' to different identity providers, with the following benefits:
Simpler code in your UIs and APIs
A single user id per user regardless of the sign in method
USER DATA
In the real world of business apps you often need to manage users and authorize requests via 2 sources of user data, as you indicate. A couple of my articles may provide some useful techniques:
User Data Management
Authorization Design
The "Two Factor" requirement is configured per user. If we have multiple applications, how do we achieve that
for application A (e.g. a webapp) 2FA is required
but for application B (e.g. a native app), for the same user, 2FA is not required (never, not even for the first time it is used)?
I'm aware of the trustComputer attribute but I don't think it helps for this problem.
Two Factor is at the User level in FusionAuth. This is by design since if the user has selected to protect their account, then they should be forced to provide their additional factor regardless of the Application they are logging into.
There isn't currently a way to change this behavior and we would need to understand the use case in detail as well as any security issues with allowing specific Applications to bypass two-factor authentication.
You can open a feature request on the FusionAuth GitHub issue tracker here: https://github.com/FusionAuth/fusionauth-issues if you want. Please provide as much detail about the use case and why some Applications allow two-factor while others don't. This will help the FusionAuth team assess the implications of adding this feature.
We are using Cognito for managing the users for our saas-application (www.contempus.be) , and are very happy with the functionality it offers.
However, there are a few aspects that we think could be better, and we're wondering if there are any tools out there that can be used to easily manage users.
Do any third party tools exist to manage Cognito User Pools?
A few features we think would be useful :
Assign groups when creating users.
Set Custom attributes when creating users.
Search users by custom attributes
Are other people also interested in these features?
Thank You,
Dries
A precursor: I've worked now in two enviroments with conflicting principals on this. I am outlining the competing ideas and would like to know which is 'correct' given the scenario described.
Scenario: Multiple applications exist on our intranet. We are implementing OpenSSO with LDAP as our authentication control and user directory. The issue comes to play is, with the LDAP authentication we know a user is allowed on the intranet but to which applications is questionable.
We intend to use LDAP to control what applications each user can access i.e. helpdesk, consultant review, report generator, survey creator etc.
The question arises in that, within each application are a significant amount of roles, and the fact that people may have multiple roles.
What is the best way to address this second area? Shoudl ALL roles be in the ldap or just the application allowances with each app database containing the more granular roles?
One approach is to use LDAP to maintain relatively high-level role information, but keep the very detailed application-specific information internal to each application.
For example, an individual might be members of LDAP groups (roles) like "employee", "help desk associate", "help desk supervisor", etc., and then the individual applications would map the high-level roles into the application-specific functions. A particular high-level role might imply access to multiple applications, and different roles would have different levels of access.
For example, a "help desk associate" might be able to create tickets, but maybe only a supervisor can delete them or run reports.
This is one of those areas where there's no one right answer. Centralizing everything in LDAP gives you better ability to report/audit individuals' access, at the cost of complicating your central LDAP schema with a lot of application-specific data. Also, depending on what existing/commercial applications you're trying to integrate, the applications may not support pulling all their fine-grained access information from LDAP.