Federated Trust Frameworks and Salesforce

This paper introduces the concept of a Trust framework, what it is, why it’s important and how we may leverage the concept from the perspective of a Salesforce based system of engagement for a citizen user.

A Trust Framework is a legally enforceable set of rules and specifications that govern a multi-party system designed to allow specific types of transactions among a community of participants. A trust framework should also facilitate the accreditation of trusted participants as part of a “ring fenced” identity federation.

In the context of this paper, Salesforce would participate as a relying party. This doesn’t preclude Salesforce acting in other participant roles and will be discussed in the fullness of time.

As citizens, our engagement with Government agencies is increasingly via digital channels. In light of current events unfolding around Covid 19, exposing a well considered omni channel engagement strategy is rapidly becoming a necessity. Furthermore, initiatives such as the NSW digital restart fund are reviewing how agency projects are funded with an increased focus on Human Centred Design and inter agency collaboration.

Leveraging a Trust Framework and a single common federated citizen identity to access said services makes sense for so many reasons.

• Customer Centric user experiences
• Cross agency experiences and insights
• Cross agency data sharing
• Opportunities for seamless value ad citizen services using a single identity
• Life Events
• Birth
• Pre, Primary and High School Education
• Tertiary Education
• Finding a job
• Property Purchase
• Marriage
• Children
• Retirement
• End of life
• Virtual Health Care Services
• Cross State, Federal and Regional integration of Trust Frameworks

The idea of a seamless citizen experience across public services is fast becoming reality and many state and federal level agencies already provide rich digital channels of engagement. However, two principal challenges must be overcome for a truly seamless experience irrespective of underlying technology and allowing agencies continued compliance with specific industry, regulatory, and privacy policies:-

Identity management; how might we securely manage a single identity across channels and agencies, respecting privacy and facilitating seamless access and secure policy based attribute sharing across services

Citizen Representation, how can we reconcile system specific models with a more generic canonical citizen model. What attributes, relationships and affiliations contribute to an overall citizen representation?

The use of Salesforce as a system of engagement is signficant and growing across both state and federal agencies. A prescribed approach to handling identity federation becomes increasingly important. In this article, we provide a potential approach as to how Salesforce can be integrated as a system of citizen engagement within a larger heterogeneous participant identity federation.

What is an Identity

An identity is a claim or statement of a physical identity (of an individual or business). Using a set of attributes representative of an entity. An identity may need to conform to a specific level of identification assurance as governed by the authenticity and veracity of it’s identity attributes,

The authenticity of an identity attribute is directly correlated to the implied authority of the attribute provider, the source of the attribute data.

As an example, a NSW license number verified by the RTA carries a higher level of assurance than a license number verified by another attribute provider as the RTA is the authoritative source for driver license numbers in NSW. Thus the framework gives relying parties a level of assurance that an identity with its composite attributes can be trusted.

Trusted Digital Identity Framework

The fundamentals and objectives of a Trust Framework remain consistent across regions, verticals, jurisdictions and implementations. This paper cites the Australian Digital Transformation Agency’s TDIF (Trusted Digital Identity Framework) as an excellent example and will use it to explain how Salesforce can participate. In the context of this paper, Salesforce would participate as a relying party (see below). This doesn’t preclude Salesforce acting in other participant roles and will be discussed in the fullness of time.

The following depicts the various Trust Framework participant roles and interactions between them

Courtesy of https://www.dta.gov.au/our-projects/digital-identity/digital-identity-system

Participant Functional Roles

• Identity service providers — help you set up and manage your Digital Identity account. If you choose to create and use a Digital Identity, then your identity provider will be your gateway into the Digital Identity system. Face Verification Service and Document Verification Service are sometimes used by your identity service provider to verify your identity online. myGovID is the government identity provider. There will more as the system develops.
• Attribute service providers — verify specific attributes relating to entitlements or characteristics of an individual (for example, that you have a particular qualification, or that you can perform certain activities on behalf of an Organisation). The ATO’s Relationship Authorisation Manager (RAM) is an example of an attribute service provider.
• Credential service providers — play a critical role in keeping the system secure and safe. They take care of all credentials such as passwords and other forms of access restrictions used in the system.
• Identity exchange — acts like a switchboard, transferring information, with your consent, between relying parties, identity service providers and attribute service providers, in a way which is secure and respects your privacy.
• Relying Party — provides a service to an entity and uses an Identity Service Provider to authenticate said entity. Can optionally use additional attributes (claims/assertions) managed by an Attribute Provider. Management of consent to attributes is managed directly with an Attribute Provider or the Exchange.

Salesforce as a Relying Party

The topic of Trust Frameworks is huge, there are a variety of facets and concerns that must be addressed. This paper focuses is a conceptual approach to a generic technical framework to better accredit and establish Salesforce as a relying party as part of a trusted identity federation. The legal, commercial and ethical framework merits further discussion but not within the scope of this paper.

The following diagram describes a high level flow for a typical authentication scenario

• Salesforce as a relying party ( RP)understands what Identity Provider(s) IDP(s) are available and what attributes are available as part of a published attribute profile and is able to request specific attributes as part of an authentication flow
• The Identity Exchange broker’s the flow between the RP , the IDP and any additional Attribute Provider(s) (AP(s))
• Core attributes are returned from the IDP, such as name, email, etc..
• Additional requested attributes are included within an identity claim and are accessed and returned from the IDP or directly via an authorised token request from the RP.
• The Identity Exchange manages conformance to attribute sharing policies where user consent requirements must be explicitly met for each RP that requests attributes, in other words the user allows and controls the required consent per RP. For example, when you allow a 3rd-party website to read your contacts from Facebook
• Consent to access attributes is managed by the Attribute provider and enforced through authorisation tokens
• Ultimately, Salesforce as the Relying Party will receive a claim conforming to an Attribute Profile. This will contain at least the Core Attribute set and optionally include additional specific attribute sets as per the any managed attribute sharing policy. Assuming the attribute owner has verified and given consent for the RP to access the attribute.

And this is where we can map attributes conforming to standardised and published attribute types, conforming to an attribute schema and governed by an attribute profile to an abstracted common model.

Citizen Common Model

Salesforce provides an extensible object schema and it’s more or less guaranteed that one Salesforce field level schema is different from another, even when they part of the same organisation. This lends some complexity to the challenge and means we need a mechanism to overlay a common model representation and map it to a Salesforce org specific schema.

This paper proposes a common model representing an identity using the Cloud Information Model.

https://cloudinformationmodel.org/

“CIM is produced by an open consortium formed to deliver a standards-based solution for connecting enterprise products. With CIM, you can create seamless and tailored personal experiences across cloud-native applications.

To accelerate digital transformation and deliver personalized engagements to customers across every channel, many companies adopt multiple cloud and on- premise applications. Each comes with its own data model, which forces developers to build, test, and manage custom code that’s necessary to map and translate data across different systems. Instead of accelerating digital transformation, this process slows innovation and leads to brittle integrations.

CIM is a modern, open specification to help ease the pain of integrating data. CIM provides a defined standard to communicate easily between different data formats. Open-sourced as part of the Joint Development Foundation (under the Linux Foundation), we welcome any and all contributors.“

At first glance this model appears complicated and it is. However, on review it has everything we need to model a citizen. Standardising on a subset of this model makes sense as : -

• It’s a vendor-supported standard and constantly evolving
• It’s a baseline that’s documented, understandable and reusable
• As regulations change increasingly complex data attributes will be available our model can evolve in step.

Typical Authentication/Authorisation Process

With that in mind, what steps can we take to ensure integrating Salesforce as a relying party is as painless as possible. Consider the following diagram describing a simplified “high leveI” sequence for an end user (Subject) to authenticate to a relying party (Salesforce) using the TDIF (Trust Digital Identity Framework).

1) Request Authentication

• End-User will request to sign in, this will redirect the user to the selected IDP.

2) Verify Credentials

• End-User will be prompted for credentials and IDP will verify credentials
• The IDP passes back the identity as a set of claims (Attributes) about the identity.

3) Request Attributes

• The Relying Party may then request additional attributes from designated and authorised attribute providers
• Attributes may be complex we must be consistent in how they are processed
• Evolving and Open Data standards mean attribute providers will expose increased data points over time

4) Serialise Attributes to Model

• Attributes are then deserialised to a common model using a proposed common implementation framework. As noted above, the common model is an abstraction from the underlying Salesforce data model and can be reused across heterogeneous implementations and is encapsulated as part of the framework.
• The attribute model may also be serialised for downstream processing

5) Process Model

• Common implementation framework provides the necessary hooks to implement or extend for org specific functionality and physical salesforce object model mapping.

Salesforce Framework

It is proposed that a generic framework can be developed to manage the serialisation/deserialisation, transformation, mapping and any subsequent processing of identity and additional attribute information. This configuration driven framework can be managed as a single deployable asset and provide the necessary extension mechanisms to accomodate org specific persistence and business logic. Managing this as a single asset allows us to preserve backwards compatibility with evolving attribute schema definitions.

Summary

This paper proposes a common pattern and the development of common components to support the integration of Salesforce as a Relying Party using an external identity to authenticate, authorise and provide ongoing context for improved and consistent customer engagement.

Some of the benefits of a consistent approach include:

Architectural Perspective

• Mostly repeatable setup of SSO configurations for participant orgs sharing same IDP/ID Exchange configurations
• Development of Common Model Framework
• Alignment common model to CIM -
• Recognised vendor standards (Salesforce are a principal contributor)
• It’s the model adopted by Customer 360 Data Manager
• Future alignment to Customer 360 Data Federation Services
• Common model abstraction means underlying org data model is irrelevant with the caveat that ultimately standardising on org data model is recommended
• Use consistent common model attributes in flows for declarative business processes
• Expedite tedious business process using consented and verified attributes
• Know Your Customer (KYC)
• Credit Checks
• Education Checks
• License Entitlements
• Potential for reuse of complex platform components leveraging the common model framework
• Adaptable and Standards based. Pattern can be reused across multiple scenarios.

What’s Next

• Investigation of use cases to verify the proposed approach is sound
• Deep dive into CIM and mapping
• Salesforce Framework Reference Architecture and Design
• Auth overrides
• *Handler overrides/implementations
• Management of 3rd party tokens
• Proposal for org specific citizen data model
• Salesforce as an attribute provider
• Evolution of open data standards
• Setup of a reference implementation
• Salesforce as a B2B Relying Party

References

NSW Government ICT Metrics Report 2016–17