B2B and Partners Access Management
Business expansion through partnerships and focus on business customers are two factors that fuel today's companies growth. Opening businesses up at scale for B2B and B2B2C relations results poses not only the benefits but also challenges for companies on how to control data sharing, delegate control, or provide self-service mechanisms for partners and customers. If your current access management tools do not support your business plans anymore, are outdated, performed manually, are not flexible enough or do not scale, offload access management to the SecureAuth CIAM platform to secure your SaaS (B2B/B2B2C) services.
The Challenge of Managing Access for B2B and Partnerships Models
Company that delivers its online services using business models like B2B and B2B2C, or is opening its services to partners need to provide and enforce access control methods to make sure that data is shared between participants in a secure manner. Additionally, the solution that company uses must ensure interoperability of all components and provide as seamless user experience for partners and customers as possible. The users (customers or partners) must be able to authenticate themselves and the scope of their access must be controlled on the organization, service, and resource (data) level.
Business that anticipate the changes early on and that adjust their solution to their needs not only secure their services better, but also keep the user experience seamless for all kinds of personas.
 |
In the diagram above, you can see how complex it is to deliver right access management tools and measures for different personas and entities. Developers, partners, customers, and also client applications (in a machine to machine environments) use different (sometimes overlapping) components of your service. Proper access control measures ensure that all entities cannot act outside of their intended permissions. Failures can lead to unauthorized information disclosure, modification, even destruction, or business functions being performed outside the user's limits.
Broken access control most common security issue in 2021
With data leaks and other threats lurking around, SaaS companies must adapt their solutions to prevent unauthorized access to resources. In the report for 2021, OWASP Top 10 organization identified broken access control as the most serious web application security risk that had more occurrences in applications than any other security-related category.
To have a solution complete and secure in its design, SaaS platforms must:
Provide partner's/customer's users with a possibility to authenticate themselves the way they usually do it or the way they want.
For partnerships or B2B and B2B2C relationships, it is crucial to provide the external personnel with means to prove their identity in a way that is convenient for them. It means that your tools need to include a possibility to integrate multiple different identity provider services.
It is recommended to use services that can also enforce mechanisms like two-factor authentication or multi-factor authentication.
Besides the personnel of your partners and customers, think of your employees too. They need to be provided with the same tools.
User authentication is done using identity provider services either available on the market or built in-house.
Enforce access control at:
The organization level
SaaS platforms that are served in the B2B model, very often need to control access at the subscription level. For organizations, only sets of features are available based on the platform's pricing plan. To cater such scenario, it must be possible to integrate your access control tool with a customer relationship management service or a billing platform. When users access the SaaS platform, it happens immediately as long as the payments for the service are billed.
Partners can be enabled to access the service for a limited time period. In other words, data is shared with partners until the partnership ceases to exist.
The service level
Users coming from your partnerships or B2B and B2B2c relationships have access only to the services (or features) the organization defined. It is possible to slice access to services based on, for example, user role inside an organization.
The resource (data) level
Access to resources is determined on additional conditions like, for example, location, time range, and others. Relies not only on the user role.
Used, for example, when the number of roles inside an organization does not allow to efficiently manage access.
Users within the same role may have different access rights. For example, imagine a situation that you need to provide users with access to your customer email base. Your sales department employee does not need access to all of the emails- they need access only to the customers they are assigned to.
Technology that is used for authorization must allow for global, application-wide configuration.
Tip
It is considered a security best practice to limit access to services and data to the resources that are absolutely necessary at the given moment.
B2B and Partnerships Access Enabler
Access Management and identity federation is the key for the security of your partner's apps, and, at the same time, it is a complex topic to handle domestically. Additionally, security best practices are constantly evolving to meet new threats. The SecureAuth Access Management platform designed specifically for B2B/ B2B2C and Partner use cases. It allows you to federate identities coming from different sources (like partners or customers) and provides powerful authorization capabilities to enforce access control at any level. With SecureAuth, achieving the Zero Trust principles is within the grasp of a hand.
What is Zero trust?
Zero trust is a security model that requires all internal and external users (or machines) to be authenticated, authorized, and continuously validated in terms of security configuration before being granted access or keeping access to applications and data. The model moves security measures from the static-network based edge to focus on users, assets, and resources.
When securing applications, one can assume two different scenarios: that every protected asset is safe and protected, or assume that the security was breached and verify all requests as if they are coming from an open network. The security of your application and data is too important to assume the first scenario. Never trust and always verify, as this is your way to go.
Identity Federation
At SecureAuth, we believe that every business should be able to configure multiple IDPs for their customers and partners to avoid proliferation of credentials, for enhanced security, and simply for the users' convenience. No partner or customer should be made to switch to a different identity provider and migrate their users for the sole integration purpose.
 |
With SecureAuth, you get:
A possibility to integrate the platform with multiple partner's or customer's existing identity and authentication providers using open standards such as OpenID Connect and SAML.
Vast number of built-in Identity Connectors for major identity providers that allows to quickly connect your identity service to the platform.
Generic OIDC , generic SAML, or Custom connectors that allows you to integrate with SecureAuth if there is no dedicated connector provided out-of-the-box.
Sandbox (static) IDP that you can set up and use for testing purposes.
A Possibility to set up and enforce MFA.
Identity Pools allow for the persistent storage of user data within SecureAuth's infrastructure, thus providing the alternative to the Bring Your Own Identity (BYOID) approach typically used by SaaS tenants.
Having added an Identity Pool to your tenant, you can connect it as an Identity Provider to specific workspaces so that the end users can log in to SecureAuth (or register in the Identity Pool first).
To learn more about Identity Pools, check the following resources:
A possibility to set up IDPControl Login Flow and dynamically discover user's identity and provide them with suggestion which IDP to use.
Access Control at Any Level
Once you have your partners' and customer's Identities set up, it is time to apply access control. With the SecureAuth platform and its features your job will be much easier. We believe that it is best to use specialized products created with their core responsibility constantly in mind and, in our case, this is authorization and access management.
We provide OAuth 2.0 authorization servers that can comply with various security frameworks (like Financial Grade API) and Open Banking requirements.
SecureAuth is shipped with built-in multitenancy. We use the concept of workspaces that contain an authorization server and integrated identities and authorizers. It is possible to add multiple workspaces of various profiles within a tenant. You can have separate workspaces for development, testing, and production environments or create separate workspaces for partners and customers.
Our authorization servers support various OAuth and OIDC authorization grant types and client authentication methods.
Coarse and fine-grained authorization can be easily set up to tailor the final access control measures exactly to the business requirements.
SecureAuth supports various authorization models like RBAC (Role Based Access Control), ABAC (Attribute Based Access Control), RISK Adaptive (Adaptable) Access Control (RADAC), or PBAC (Policy Based Access Control) to allow choosing most suitable method for every component of the system.
Access can be controlled at any level: organization, service (feature), resource.
For protecting your applications and APIs, SecureAuth provides Authorizers which our built in-house deployable integration points for major major API gateways and Service Meshes.
Authorizers allow the SecureAuth platform to fetch APIs and services from the gateway/service mesh so that it is possible to assign authorization policies and enforce access control.
Policies are the key to protecting applications and services with SecureAuth. SecureAuth offers several use-case specific policy types, which can be defined either in the native SecureAuth policy engine or using the Rego standard.
Policies can be applied on both application and service/API level. One non-obvious use-case for policies could be subscription management for end users, where features are enabled based on the claims issued to the application by SecureAuth.
Make sure that the correct users get access at the right time
Control the application access levels available to users based on their subscription data, which can be included in claims issued by SecureAuth.
Recommend the application features not yet available to a given user based on their subscription data.
Policy type
Description
User
User policies validate requests involving user interaction (for example to determine whether or not a client can ask the user for access to certain data). They can be assigned on a workspace level (Token issue policy), application level (User policy) and service scope level (Consent grant policy).
Developer
Developer policies validate client registration, including the scopes the client may ask for. They can be assigned on a workspace level (Client registration policy) and service scope level (Client assignment policy).
Machine to machine
These policies validate a token request coming from a client using the Client credentials OAuth 2.0 flow. They can be assigned on a workspace level (Machine token policy) and service scope level (Machine to Machine policy).
Dynamic Client Registration
DCR policies are used to validate Dynamic Client Registration requests.
API Request
An API policy validates requests coming to APIs protected by a gateway bound to SecureAuth.
We provide a developer portal functionality that allows the developers to register and manage their client applications. Additionally, applications can be dynamically registered with the use of SecureAuth APIs.
For partnership and customer enablement, you can use the Token Exchange grant type or use third-party access tokens for access control.
Let's Get You Started
To get you started with enabling B2B and partnership scenarios at your company we identified some steps you may take first. For instructions, see SecureAuth CIAM.