On Wednesday 11th December, we presented the latest Customer Data Cloud Webinar with a focus on the new SAP CIAM for B2B solution. The presenters of the session were:

• • Ratul Shah – Senior Product Marketing Managers, SAP Customer Data Cloud

 

• • Stephen Purvis – Product Expert, SAP Customer Data Cloud

 

• • Chris Rushton – Senior Implementation Consultant, SAP Customer Data Cloud

In this webinar, we both outlined the key features that make up SAP CIAM for B2B and subsequently how easy it is to configure and implement the solution. You can find a link to the recording here.

This blog post focuses firstly on those features, providing a background to topics that are new to both the product and the market. These include:

• • Partner Organisation Management
    • • Organisation Registration
    • • Delegated Administration

 

• • Policy-Based Access Control

 

• • Authorisation Centralisation

In order to anchor these features a real-world example, we’ll introduce a demo company whose use-cases we’ll provide solutions to.

Secondly, this article provides a step-by-step guide on how to configure SAP CIAM for B2B for the real-world scenario presented.

My IOT

My IOT are the leading supplier of IOT devices to offices across Europe. They specialise in The Internet of Meeting Rooms, smart devices that facilitate the scheduling of meetings in rooms across offices.

They work with a number of Partner Organisations, many of whom simply purchase devices to then be installed within their offices. These Partner Organisations would include, for example, SAP.

My IOT offer a ‘Business Portal’ website where users – stakeholders of the Partner Organisations – can navigate to in order to conduct some form of transaction with My IOT. These stakeholders may include ‘Buyers’ who go to the Business Portal to purchase devices, or ‘Technicians’ who need to download installation guides in order to help them with implementing the device.

Personas

Before running through the CIAM for B2B features, it will be useful to provide an overview of the personas – and the terminology used around those personas – in order to ensure an understanding of who interacts with the CIAM for B2B solution and how they interact with it.

IT Admin

In our scenario, an IT Admin is someone who administers Organisations on behalf of My IOT. Whilst they are labelled as an IT Admin, they do not necessarily have to be a member of the IT team.

Their two core functions are:

1. 1. Approving Organisations

 

1. 1. Creating Policies that determine access management, encompassing:
      1. 1. Creating Roles to be used by Partner Organisations
      1. 1. Creating Assets that provide or restrict access based on the user’s Role

We will talk about Policies – including Roles and Assets – further on within this article.

Delegated Admin

In our scenario, a Delegated Admin is someone who works for a Partner Organisation of My IOT, such as an Organisation who purchases devices from them. The Delegated Admin has the ability to invite further users – such as the ‘Buyer’ we discussed – to allow them to access Assets made available by My IOT, such as the ‘Buyer’ having access to an ‘eCommerce’ asset that allows them to access an eCommerce application.

Thus the Delegated Admin has one core function:

1. 1. To invite Organisation Members – assigning them a role – that determines access management

 

Organisation Members

In our scenario, Organisation Members are stakeholders of the Partner Organisation who want to access some form of Asset. In our example, a ‘Buyer’ working for one of My IOT’s Partner Organisation wants to access an eCommerce application in order to purchase IOT devices to be installed within the Partner Organisation’s offices.

In this example, the application itself is an Asset.

Partner Organisation Management

Partner Organisation management is a key component of the CIAM for B2B solution. Previous IAM solutions that focused on Role and Attribute-Based Access Control (RBAC and ABAC, respectively) mandated that both management of Partner Organisations and management of the Partner Organisation’s stakeholders was the resolve of your organisation. In our example, this would be the central IT team for My IOT managing the technical onboarding of Partner Organisations and the onboarding of Partner Organisation stakeholders. This process is not just time-consuming and a cost-drain for My IOT, but will also lead to long lead-times for the Partner Organisation to onboard users of the Business Portal.

The SAP CIAM for B2B solution provides the ability for My IOT to only have to take on the management of Organisations and then assign responsibility for Partner Management to a delegated user (or users) within the Partner Organisation. This reduces the burden of both time and cost on My IOT’s central IT team and streamlines the process for Partner Organisation users to get onboarded.

Organisation Registration

Organisation Registration becomes a key component of the CIAM for B2B solution when delegating Organisation Management to the Partner Organisation. Any time a Partner Organisation is provided the ability to manage their stakeholder access, the Organisation needs to exist within the CIAM for B2B; until that point, stakeholders cannot be assigned to that Organisation.

There are 4 main processes to create Organisations within the SAP CIAM for B2B:

1. 1. Self-Registration

 

1. 1. API Integration

 

1. 1. Migration from Existing System

 

1. 1. Manual Creation

One of the biggest differentiators to the CIAM for B2B solution is the ability for Partner Organisations to register themselves. In order to facilitate this, you can take advantage of out-of-the-box screen-sets being made available by the SAP CDC:

If you’re familiar with screen-sets, then you’ll know that this UI can be created using a Drag&Drop editor and surfaced to your application with just a single line of Javascript. The screen-set above is the one used for Organisation Self-Registration on the My IOT Business Portal website. As you can see, we capture both company details and the contact details of the user who is requesting the Organisation is registered.

The user registering the Organisation is also created as the Delegated Admin, a role that we will discuss further on in this article.

When an Organisation is self-registered, the IT Admin – in our case, one working for My IOT – is required to approve the Organisation. On submission of the form, the user will be informed of this fact:

And on submission of the form, when the My IOT IT Admin navigates to the CIAM for B2B console, they will see the Organisation waiting with a status of ‘Registration Request’. In order to find these Organisations, the IT Admin will first navigate to the ‘Organisations’ tab of the Console, where they will be able to select from the different statuses available:

Specifically, we want to select the ‘Registration Request’ tab:

Our objective as the IT Admin is then four-fold:

1. 1. To review the Organisation

 

1. 1. To ensure that any relevant back-end processes have been completed

 

1. 1. To add a BPID

 

1. 1. To approve/reject the Organisation

All of the above can be completed from the Organisation Management screen, after we have selected our Partner Organisation ‘Webinar Blog Company’:

As has been noted at various points in this article, Organisation Registration is often supported by back-office processes that are mandatory to facilitate a relationship with a Partner Organisation; these include contracts, legal arrangements and procurement discussions. As a result, it may well not be a member of My IOT’s IT team who administers the Organisation; it could be a user working within My IOT’s Legal or Procurement team and so can work with other back-office teams to ensure that these processes have been completed before approving the Partner Organisation.

If these processes have not been completed, the IT Admin can use the information displayed on this screen to contact the user who requested the Organisation Registration to facilitate the completion of these processes.

At the point that we approve the Partner Organisation, we are also prompted to add a BPID. The BPID is a Foreign Key to the CIAM for B2B system, providing an identifier to the Partner Organisation within the CIAM for B2B data model and linking the Partner Organisation to its equivalent in other back-end systems that will also store information about the Partner Organisation. These systems will most predominantly be an ERP system that is used to store transactional information or a CRM that is used to store Partner Organisation contact information.

Whilst the BPID should be populated when a Partner Organisation is created via API or a migration, this field will need to be manually entered by the My IOT IT Admin when the Partner Organisation is created via Self-Registration.

After we approve the Partner Organisation, we can ‘Send for Approval’:

Sending the Partner Organisation for Approval allow us to use a custom approval flow; for example, the IT Admin for My IOT may work as part of the central IT function because My IOT trust them to use a technical system. However, final approval may only be given by a member of the Procurement team and so My IOT can configure an email to be sent to the Procurement user prompting them to additionally approve the Partner Organisation.

Webinar Blog Company now has a status of ‘In Progress’:

On additional Approval, the Partner Organisation will be created and an email will have been sent to the user who request the Self-Registration inviting them to finalise their Delegated Admin account.

Delegated Administration

As we have covered briefly, the Delegated Admin works on behalf of the Partner Organisation; in our scenario, we created Webinar Blog Company with user christophermrushton+webinarBlogCompany@gmail.com as the Delegated Admin. The function of the Delegated Admin is to invite Organisation Members who wish to access Assets being made available by My IOT; in our scenario, the Delegated Admin for Webinar Blog Company will want to invite someone from their Procurement Team to purchase IOT devices from the My IOT Business Portal.

When a Delegated Admin is first created, they are delivered an email requesting that they finalise their account. In order to do so, they can clickthrough on a link in the email to access the My IOT Business Portal and subsequently be presented with a screen-set requesting the Access Code provided in the email and for the Delegated Admin to create their own password:

We can even take advantage of our Consent module that is part of our out-of-the-box CIAM for B2C solution and request the Delegated Admin provides consent to use the My IOT Business Portal:

Delegated Admins have access to their own Delegated Admin Console from which they can invite Organisation Members. At the point of logging into the Business Portal, an access decision – the same as is made for Organisation Members – will provide a response to the application letting it know that the user is a Delegated Admin. The application will interpret that response and provide the Delegated Admin with access to their Console only:

Clicking through on this tile will take the Delegated Admin to the Delegated Admin Console from where they can invite additional users to their Partner Organisation:

When inviting users, after clicking ‘Invite’ Delegated Admins are prompted for key pieces of information about the Organisation Member:

The Delegated Admin adds information about the Organisation Member such as their forename, surname and email address. However, they are also prompted to add a ‘Business Role’; this is a dropdown list of Roles configured by the My IOT IT Admin to be selected from by the Delegated Admin. We discuss ‘Roles’ further on in this article, but the Role that is selected here will determine what access the Organisation Member has after logging into the application.

Organisation Members

Organisation Members are users from Webinar Blog Company who wish to access an Asset – such as a website, or content within a website – that My IOT want to protect. In our scenario, My IOT provide a number of different applications within the Business Portal that they want to govern access to such as the eCommerce application; only users who have the required access rights should be able to access the application in order to purchase IOT devices on behalf of Webinar Blog Company.

When a Delegated Admin invites an Organisation Member, following the same process as when a Delegated Admin is invited to create an account the Organisation Member will receive an email with an access code and a link to the Business Portal which they’ll use to create an account with a password.

On logging in, the Business Role that the Organisation Member was assigned will govern the access response provided to the Business Portal; it is this response that will determine what Assets are provided back to the Organisation Member:

In our scenario, we’ve invited the user christophermrushton+webinarBlogCompanyBuyer@gmail.com with the Business Role as ‘Buyer’. The Business Role of ‘Buyer’ provides me access to Assets tagged as ‘eCommerce’ or ‘eLearning’; in our scenario, this manifests itself in the Business Portal providing access to the ‘Shop’ and ‘eLearning’ applications thus allowing the user to purchase IOT products on behalf of Webinar Blog Company.

Now that we’ve introduced the different personas, let’s dive into what makes up Policy-Based Access Control and how it is configured.

Policy-Based Access Control

A Policy can be distilled into three questions:

1. 1. Who should have access?

 

1. 1. What should they have access to?

 

1. 1. When should they be provided access?

The answer to these questions will then determine the access decision, where this decision determines what Assets a user should have access to.

Who

Where legacy IAM solutions using a Role-Based Access Control (RBAC) model will traditionally conflate a role as being both the ‘Who’ and the ‘What’, leading to the ‘role’ not being a human legible role but rather a conflation of role and function. Due to this, we experience something called ‘Role Explosion’; the roles that are available to be selected from far outnumber the Business Roles that exist within the Partner Organisation. In order to solve this, the SAP CIAM for B2B solution refers to roles in the sense of a Business Role.

The Business Role is designed to be read by the Delegated Admin, who will assign a Business Role to the Organisation Member. One of the benefits to giving responsibility for Partner Organisation Management to the Partner is that the Delegated Admin should know their business; in our scenario, the Delegated Admin for Webinar Blog Company should know their business better than My IOT. As a result, they should know which Business Role to assign to which Organisation Member.

This Business Role is then what defines the access decision for the user that is logging in and ultimately determines the ‘What’.

Attributes

 

• • Talk about Attributes

 

What

Legacy IAM solutions using an Attribute-Based Access Control (ABAC) model will ordinarily use attributes as both the ‘Who’ and the ‘What’, where either a single attribute or combination of attributes are selected to determine who the user is and what they should have access to. Limitations of this system are that attributes are often too specific to either a Role or an Asset, or that an attribute doesn’t exist for the Asset. Attributes are then either misused or new attributes are required for every new Asset, requiring constant management. In order to solve this, the SAP CIAM for B2B solution offers the ability to manage ‘Internal’ or ‘Virtual’ Assets and combine them with the Business Role.

Internal Assets are more static, less liable to change and lower in number; think a website, or categories of content within a website. We even experience Functional Roles as Assets, where a system such as SAP Commerce Cloud has Functional Roles built-in – such as Admin, or Manager – that inherently offer access to Assets. Internal Assets are created within the CIAM for B2B system and do not have to be managed in an external repository.

The same cannot be said for External Assets. External Assets are often higher in number and are more dynamic or prone to change; an example would be pharmaceutical drugs where an inventory may run into the hundreds of thousands. These External Assets would be managed in an external repository

Assets are always based on a Template; this Template defines attributes that are used to describe the Asset. For example, the My IOT Business Portal uses the category to define which Assets are provided to which Organisation Member; for the Buyer access the eCommerce application, this was the ‘eCommerce’ category.​

 

When

‘When’ is perhaps not the right term to describe an additional constraint that can be added to the access decision; the Condition can be a time constraint – such as the time of day – or another constraint such as IP address or device type. The Condition is designed to offer a further constraint to the access decision in addition to the ‘Who’ and ‘What’ question; for example, I may only be able to access a certain pharmaceutical drug during a specific month of the year and this is something that could be controlled with a Condition.

We should underscore the fact that the Condition is an additional add-on to the Policy; in most cases we only need to factor in the ‘Who’ and the ‘What’.

Authorisation Centralisation

Let’s take the scenario that we have already introduced and break down the Policy requirement into a human-legible use-case.

We have:

• • A user for Webinar Blog Company who wants to be able to purchase products from an eCommerce store made available within a Business Portal by My IOT

By breaking this down, we know we have:

1. 1. A company – Webinar Blog Company – that has already been created

 

1. 1. A user who needs to be able to purchase something; we can call this Business Role a ‘Buyer’

 

1. 1. An eCommerce store that the user needs to have access to

 

1. 1. A Business Portal that the eCommerce store is made available in

Before Organisations are created or approved, the IT Admin for My IOT will configure Policies that will facilitate this use-case. To do so, they’ll navigate to the CIAM for B2B console and go through the following steps.

Policy Configuration

On the left-hand side of the CIAM for B2B console menu, we have the ability to select ‘Policies’ and review all Policies that have been configured:

We’ve already configured the Policy required to provide a ‘Buyer’ access to the eCommerce application within the My IOT Business Portal so let’s first provide an overview of the Policy:

The Policy connects the ‘Who’ on the very left, with the ‘What’ on the right; as you can see, we also have the relevant Application (the Business Portal) and also the ability to configure a Condition, which for this use-case we aren’t required to do. Now that we know what a Policy looks like, we can breakdown how each of the components of the Policy are configured.

Applications

Within the ‘Implementation’ tab of the CIAM for B2B console we can configure the Asset or a list of Applications that the Assets belong to:

The Authorisation API call for each Application occurs server-side. Creation of an Application is required to ensure that a clientID and secret are generated for for use by that Application in signing the Authorisation request. Whilst we won’t go into detail in this article on the technical requirements for the Authorisation request, we’ll note here that the clientID and secret are used to generate a bearerToken per-Application with this bearerToken passed with the request.

Given each Application may be supported by different, disparate stakeholder groups we create each Application individually and thus generate unique clientID:secret pairs. As you can see below, we have created the ‘Portal’ – this being the Business Portal – with a clientID and secret available by selecting the Key icon:

Assets: Actions

Actions provide information to the Application about what function the user should be provided for the assets that are returned in the Authorisation response. For example, whilst in our scenario we simply need to provide ‘Access’ for the Buyer to the eCommerce application this may be different for other scenarios. We may choose to have ‘View’, ‘Edit’ and ‘Create’ as Actions that would provide information to the Application on how the user is to interact with those Assets they have access too.

As-above, for our scenario we simply need to create a new Action called ‘Access’:

Assets: Templates

All Assets are based on a template that defines what attributes are used to describe that Asset. For example, in our scenario we will categorise our Assets – the eCommerce and eLearning applications – with a ‘category’ attribute value and determine what access should be provided for any Asset that has a ‘category’ attribute defined; in our case, it’s the ‘Access’ Action that we created above:

Assets: Template Management

Once we’ve completed all of the steps above, we’re ready to combine them to create the Asset itself. Here, our goal is to define what attribute value we’re using to categorise this Asset; for the eCommerce application, we’re assigning the value ‘commerce’:

In the Authorization response, where a user has ‘Access’ to an Asset where the value of the ‘category’ attribute is ‘commerce’ then any Assets within the Business Portal that are tagged with the ‘commerce’ flag will be served to the user.

Roles

A Role by itself is primarily a signifier to the Delegated Admin as to what function the Organisation Member is a part of or what actions they will complete; for example, we labelled our Role as ‘Buyer’ because all users with that Role can purchase IOT devices on behalf of Webinar Blog Company.

The Organisation Member’s Role then determines the Policy or Policies that subsequently provide or restrict access to the created Assets.

Here we have created the ‘Buyer’ Role and can see the Policies, Assets and Applications associated with this Role:

Conclusion

In this blog post we have introduced the core concepts that drive the SAP CIAM for B2B solution, presented a real-world scenario and provided the steps to configure the SAP CIAM for B2B solution in order to run this real-world scenario.

In future articles we will cover External Assets and Dynamic Lists, including the Policy configuration for each. In addition, we will present the technical integration side of the SAP CIAM for B2B solution, including the Authorisation request, creating a bearerToken and interpreting the responses.