@Caute_cautim wrote:Interesting situation arose, shared client infrastructure using the same source IP address range. Salesforce Authentication uses SAML and XML messages, by default without MFA etc.
What happens if you have a business contract, which prevents users from seeing information from another organisation (insurance acquisition), but the original organisation is still in migration mode for months to come. So one user from the organisation goes through to Salesforce, using the same IP address (shared infrastructure), and due to the current remote working situation (COVID-19) and they are forced to used BYOD to keep the business up and running.
Source IP really should not be used as an authorization factor (e.g. to which organizational unit the user may access). Instead, the SAML IdP (Identity Provider) should return said authorization in an attribute. This ensures that if an employee visits the other unit, their authorization remains consistent.
Now that we are all in the midst of work-from-home mandates, the use of source-IP as part of the IAAA process really shows its limitations. It took my colleagues a few years of dealing with a mobile work force and mergers/acquisitions to come up with a few SAML strategies that seem work well for us:
- All aspects of authentication are done by our IdP. For example, we would not use Salesforce OTP or Salesforce geolocation. Instead, our IdP handles those tasks internally (and consistently across all SPs - Service Providers).
- We use Geolocation to determine which authentication factors are required. For example, if one is onsite, we accept NTLM or Username/Password. When offsite, we add an OTP requirement. We are contemplating adding a third factor when in countries where we have no business or when geolocation indicates improbable travel (e.g. over 1,235 km/h). However, we do not use GeoFencing to completely block access. There are enough border cases and database errors that users need a way to react when it flares up.
- Significant access roles (admin, manager, user, org unit, etc.) are best kept in corporate AD (or whatever you use for identity management) and handed off to the SP by attribute. This keeps your core security team in charge of the fundamental access decisions and more quickly able to modify/remove access.
- App settings and preferences best remain with the SP. Our general rule is that SAML only sends mandatory things via attribute. For example, if the default should be "Compact View", the SP sets it initially and keeps track of the user's preference. On the other hand, our IdP often sends "email address" because it needs to be "right" and users can not change it.
- Just-in-time provisioning can be your friend, but you still need a sync process to handle deprovisioning.
- SAML becomes an easy "sell" when admins realize how simple it is to comply with account life-cycle management requirements (i.e. refer the auditors to the AD team).
Like most things, after one has a dozen or so SPs, it becomes more obvious where the line in the sand should be drawn between the IdP vs the SP.
