Identity and Access Management – Identity Management Concepts

Identity and Access Management for Beginners

Secure Assets: 

  • Grant least amount of privilege
  • Allow only the appropriate level of access
  • Utilize multi-factor authentication

Empower Users: 

  • Reduce the number of username/passwords they juggle
  • Reduce bad password practices
  • Have centralized account managment
  • Enable seamless workflows across solutions and services

Authentication –>Authorization

With authentication we are verifying which service is requesting the access and which user is it acting on behalf of. For authorization now that service has access, what is it allowed to do? 

Connected Apps

These describe a connected service, the users who should/should not have access and how to authenticate in. 

Guaranteeing seamless access

Identity Provider (IdP)

  • manages identity ifnormation for users
  • provides authentication services to downstream application
  • may provide corollary user details (org ID, language, locale)

Examples of Identity Provider

  • Salesforce
  • Any third-party web app that implements OpenID Connect Protocol
    • Amazon
    • Azure
    • Facebook
    • Google
  • Custom External Authentication Provider

Single Sign On

1. Users don’t have to remember lots of passwords

2. Admins don’t have to troubleshoot

3. Developers build web and mobile application sthat can work seamlessly

4. CIOs strengthen security and trust

5. Customers collaborate 

6. Partners can integrate

Services and APIs are exposed in other systems

– Cloud storage services

– Analytics services

– Tax calculation services

Resources in those systems  may include Record data and/or files

Two Levels of Security

Generic Permissions

  • API Access
  • Custom permission access
  • Visualforce access
  • Ability to request fresh access tokens

User and Service Specific Permissions

  • CRUD/FLS
  • Record level sharing
  • System Permissions
  • Licensing

How do I protect my data?

To protect your data you must: 

1. Protect secrets

2. Allow users/admins to revoke access remotely

3. Set reasonable access lifespans

To help do this you should: 

1. Enforce multi-factor authentication

2. Impose other restriction levels (permitted IP ranges, login hour restrictions)

Methods of Authentication

OAuth 2.0 Protocol

Protocol Name Use it When How it Works
Web Server Authentication Flow User is present User authenticate and approves the use of the applications which requests an access token
SAML Bearer Assertion Flow You want to authenticate servers without interactively logging in A SAML Bearer Token is used to request an access token
JWT Bearer Token Flow You want to authenticate servers without interactively logging in Use of  JSON Web Token (JWT) Bearer Token in the request
Username-Password Flow Avoid in production – use if required for proof-of-concepts Explicit use of the username and password in the request

 

 

OAuth With Salesforce Demystified

Authentication

Who are you? Similar to checking in to a hotel this is the identification process.

Authorization

Now that I know who you are, these are the things you are allowed to do. Think of this like opening your room at the hotel. Authorization cannot occur without Authentication.

OAuth 2.0

This is an open protocol that allows secure authorization in a simple and standard method from multiple sources including web, mobile and desktop applications. This allows a 3rd party service to access information using someone’s credentials without exposing their password. This allows developers to no longer store passwords inside source code. OAuth 2.0 is designed only for Authorization but does not represent a users identity, the access token does not represent a users identity. However, OpenID Connect can be used to help provide Authorization and Authentication.

 

Image from OAuth with Salesforce Demystified

 Tokens

Tokens are used in place of usernames and passwords and grant access to specified resources for a specified duration.

Access

Short lived token that allows the application to access the user data (In Salesforce this is the session ID)

Refresh

A long lived token used to acquire a new access token, these can be revoked.

ID Token

Token related to OpenID Connect

Connected App

A special app that uses Salesforce API’s using OAuth 2.0 These can Authenticate, provide single sign on and acquire access tokens. You can provide information to them like redirect URLs scope of access. Once you have configured a connected app you will recieve a Client ID and a Client Secret. You can control user access to the app using Permission Sets and Profiles.

Client ID and Client Secret

Client ID – public identifier for your application – should be unique and non guessable

Client Secret – only used in the web-server flow, do not include in mobile or browser based apps

OAuth Scopes

The scope provides selective enabling of access, the scope control the types of resources available

Some scopes include:

  • api
  • chatter_api
  • full
  • id
  • refresh_token
  • web

OAuth Flows in Salesforce

  • Web-Server Flow
  • User-Agent Flow
  • Username-Password Flow
  • SAML Bearer Assertion Flow
  • JWT Bearer Token Flow
Name Use When Type Reason
Web Server Flow You have a web application running on a server that can securly store the consumer secret Used by web server applications which need to interact with Force.com API’s on behalf of use. Web apps run on a server where the code is not publicly available Higher degree of security because the client secret is protected
User-Agent Flow You have a client side mobile/browser application which cannot secure the client secret
Username-Password Flow Used by applications that work without requiring user interaction to actively give authorization
SAML Bearer Assertion Flow A signed SAML 2.0 Assertion along with a digital signature can be used to obtain an OAuth access token
JWT Bearer Token Flow Server-to-server API integration uses JSON Web Token (JWT) to obtain an OAuth access token

From OAuth With Salesforce Demystified

User Authentication

Identity Basics

Salesforce Licensing

How to Provision Salesforce Communities Users

Provisioning Account, Contacts and Users

1. Create the contact record (must be attached to an account)

2. Create a user record from the contact and assign a user profile that has access to your communicaty

Contact Associated With Available Provisioning
Person Account Customer Users
Non-Partner Account Customer Users
Partner Account Customer and Partner Users

To make an Account a Partner Account by selecting Manage External Acocunt > Enable as Partner

External users can be created by Salesforce users or other external users who have delegated admin permissions as summarized in this table:

License

Permission

User can create…

Salesforce

“Manage External Users”

Users on Accounts he has read access to

Partner Community and Partner Portal

“Delegated External User Administrator”

Users on his Account

Customer Portal Manager and Customer Communities Plus

“Delegated External User Administrator”

Users on his Account

Provisioning Options

Manual Provisioning

Initiate from the contact record and Manage External User

Self Registration

In B2C Communities users can be directed to a Self Registration page and Salesforce can create the contact and user records

API Provisioning

Using SOAP or REST APIs on the user object you can create a community user (but you must set the contact and account ids when doing so and the account must be owned by a Salesforce user with a role)

Social Sign-On Provisioning

Social Sign On can allow your users to authenticate from other identity providers. Items like Facebook, Google, Microsoft, Amazon, Paypal and any OpenID connect.

Just-In-Time Provisioning over SAML

A SAML assertion can be used to create a regular and portal user on the fly the first time they try to log in. Your org must have SAML-based single sign-on enabled to use this functionality. JIT does not support person accounts.

Enable provisioning over SAML

1. Enable Just-in-Time provisioning (must be explicitly enabled)

2. Construct your SAML Assertion – add a series of attributes to a normal single sign-on message

  • Account Attributes
    • Account.Name (string 255 or less)
    • Account.AccountNumber (40 characters or less)
    • Account.Owner (15 or 18 digit characters Salesforce Id)
  • Contact Attributes
    • Contact.LastName (String)
    • Contact.Email(A unique email address)
  • User Attributes
    • User.LastName (string)
    • User.Email (string in form of email address)
    • User.Username (string in form of email address must be unique)
    • User.ProfileID (string id of appropriate profile)
    • User.PortalRole: (Worker, Manager, or Executive)

 JIT Provisioning Sequence

Mass-User Provisioning

Data Loader

Once you have configured the Community Accounts you can add contacts to the accounts and create users with the correct profile, role and related records. 

Bulk User Provisioning via API

You can use the createPortalUser and createPersonAccountPortalUser to create users in bulk. 

Using Identity Connect to Integrate with Activity Directory

Salesforce Identity Connect can be used to synchronize with Active Directory. 

Single Sign-On

When you set up SSO, you configure one system to trust another to authenticate users. For each scenario you can configure the authentication protocol to use. 

Salesforce as the Service Provider or Relying Party If your company already has an identity provider. 
Salesforce as the Identity Provider or OpenID Connect Provider Salesforce acts as the identity or authentication provider to third-party service providers. Can use OpenID Connect to enable Salesforce as an OpenID provider. 
Salesforce as Both By chaining identity providers together you can have Salesforce act as botht he identity provider and the service provider
Salesforce and Delegated Authentication You can use delegated authentication to enable users to log in to multiple apps with the same user credentials.

Terminology

Federated Authentication With federated authentication, users log in one time to access multiple apps. For example, you log in to your Salesforce org and from there can access your company’s benefits app, Workday.
Security Assertion Markup Language (SAML) SAML is an open standard authentication protocol that you can use to implement SSO in your Salesforce org. SAML allows identity providers and service providers to securely exchange user information, enabling user authentication between services.
Identity Provider An identity provider acts as a trusted service that authenticates a user’s identity.
Service Provider A service provider is the application a user wants to access, such as a Salesforce org or a third-party app like Workday.
SAML Request When a user attempts to access the service provider, the service provider sends a SAML request asking the identity provider to authenticate the user.
SAML Response To authenticate the user, the identity provider sends a SAML response to the service provider. The response contains a signed SAML assertion with facts about the user.
SAML Assertion A SAML assertion, which is part of a SAML response, describes a user by asserting facts, like username or email address. During authentication, the identity provider signs the SAML assertion and the service provider validates the signature.
Just-in-Time (JIT) Provisioning Use JIT provisioning with SAML SSO to automatically register a user account with the service provider the first time a user logs in. For example, a new employee logs in to Salesforce for the first time with SAML SSO. JIT provisioning automatically registers a new user account in your Salesforce org for the employee.
OpenID Connect OpenID Connect is an open standard authentication protocol built on top of OAuth 2.0. With OpenID Connect, the relying party and OpenID provider can exchange information about who a user is and what they can do with a service.
Custom Authentication Protocol This general term describes any custom authentication protocol that can be used with an authorization service, such as OAuth. Custom authentication protocols have the same core functions as OpenID Connect, but they don’t conform to the OpenID Connect standard.
OpenID Provider In OpenID Connect, an identity provider is called an OpenID provider. It authenticates users as requested by the relying party.
Authentication Provider An authentication provider is a framework that allows you to connect Salesforce to a third party for authorized data access, authentication, or both, depending on the protocol. Authentication providers can implement OAuth 2.0 to authorize Salesforce to access third-party data. Or they can implement OpenID Connect or custom authentication protocols to support both third-party data access and authentication.When you’re using authentication providers, Salesforce is always the relying party. If the authentication provider implements OpenID Connect, we refer to the third party as the OpenID provider. If it implements a custom authentication protocol, we call the third party the identity provider.
Relying Party In OpenID Connect and custom authentication protocols, a service provider is called a relying party, though some use the terms interchangeably. It relies on the OpenID provider or identity provider for authentication.

Require Users to Login with SSO

1. Prevent logins through login.salesforce.com by updating My Domain policies under Company Settings

2. Disable Salesforce credential logins under the Single Sign-On Settings > Delegated Authentication – Disable login with Salesforce credentials

3. Enable SSO at the profile level by updating Is Single Sign-On Enabled from the Administration Permissions section of the profile (this can also be done with a permission set)

SAML SSO Flows

Service Provider-Initiated SAML Flow

Identity Provider-Initiated SAML Flow

Salesforce as a Service Provider

Define an Identity Provider with SAML

Use an Authentication Provider

1. Use a predefined authentication provider

2. Set up an authentication provider

3. Create a custom authenticatin provider for a third party that support OAuth 2.0

Salesforce as an Identity Provider

1. Integrate Service Providers with SAML 2.0

2. Integrate Service Providers with OpenId Connect

Salesforce as Both the Service Provider and Identity Provider

1. Create an Identity Provider Chain

2. Configure SAML SSO Between Multiple Org or Experience Cloud Sites

3. Configure SSO Between Orgs with the Salesforce Authentication Provider

Single Sign-On for Portals and Sites Fun Facts

  • You can use only SAML version 2.0 with portals and Sites.
  • Only customer portals and partner portals are supported.
  • Service provider initiated login isn’t supported.
  • For portals, the portal_id and organization_id attributes are required. If only one is specified, the user receives an error.
  • For Sites, the portal_id, organization_id, and siteUrl attributes are required. If only one is specified, the user receives an error.
  • For portals, if both portal_id and organization_id attributes are populated in the SAML assertion, the user is directed to that portal login. If neither is populated, the user is directed to the regular SAML Salesforce login.
  • For Sites, if all the portal_id, organization_id and siteUrl attributes are populated in the SAML assertion, the user is directed to that Sites login. If the siteUrl isn’t populated and the other two are, the user is directed to the portal login.
  • More than one portal can be used with a single org.

Single Logout

Session Index Support: Salesforce support session index parameters in requests and responses with SAML SLO, the session index parameter is required to identify which user session to end. SLO can assist with time saving and increased security. 

Delegated Authentication

Set up delegated authentication so users can log in with credentials managed by an external authentication method.

1. When user tries to log in Salesforce tries to validate the username and checks the user’s permissions and access settings

2. If  Is Single Sign-On Enabled permission is enabled for the user Salesforce calls the SOAP-based SSO web services to validate the username and password

3. The web service call passes the username, password and source IP to SSO web service implementation, which Salesforce servers then access. The source IP is the address where the login request orginated

4. Your SSO web service implementation validates the passed information and returns either true or false

5. When the response is true, the login process continues, otherwise the user gets an error message that the username and password combination is invalid. 

 

 

Event Monitoring

Event Monitoring Analytics App

Real-Time Event Monitoring

Enhanced Transaction Security

Shield Platform Encryption

Auditing

Record Modification Fields

All objects include fields to store the name of the user who created the record and who last modified the record. 

Login History

Review a list of successful and failed login attempts for the last six months.

Field History Tracking

You can enable individual field auditing. This is available for all custom objects and some standard objects. 

Setup Audit Trail

Administrators can view the setup audit trail, 

Submit a Comment