Skip to content

Commit

Permalink
Update usage of organization to marketplace where applicable orderclo…
Browse files Browse the repository at this point in the history
  • Loading branch information
Crhistian committed Apr 15, 2022
1 parent 221fdb5 commit 9e5a652
Show file tree
Hide file tree
Showing 11 changed files with 40 additions and 40 deletions.
42 changes: 21 additions & 21 deletions content/documents/access-control-using-portal-teams.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -10,25 +10,25 @@ tags: ["Portal"]

## What is access control

Access control in the OrderCloud Portal is the concept of managing a relationship between an Organization you administer and a Portal user or team of users. Each relationship has a set of permissions related to features in the Portal and a list of OrderCloud API roles for controlling data access.
Access control in the OrderCloud Portal is the concept of managing a relationship between a Marketplace you administer and a Portal user or team of users. Each relationship has a set of permissions related to features in the Portal and a list of OrderCloud API roles for controlling data access.

Upon choosing to invite a new Portal user or team to contribute to your Organization, you will be asked to define these relationships. Once the invitee accepts your request, they will be able to view and/or manage your Organization and the data within it, depending on their level of access.
Upon choosing to invite a new Portal user or team to contribute to your Marketplace, you will be asked to define these relationships. Once the invitee accepts your request, they will be able to view and/or manage your Marketplace and the data within it, depending on their level of access.

## Organization access controls
## Marketplace access controls
<figure class="blog-figure">
<img src="/images/knowledge-base/inline/access-controls/org-access-controls.jpg" alt="Organization access controls"/>
<figcaption>A typical Organization access form in the OrderCloud Portal.</figcaption>
<img src="/images/knowledge-base/inline/access-controls/marketplace-access-controls.png" alt="Marketplace access controls"/>
<figcaption>A typical Marketplace access form in the OrderCloud Portal.</figcaption>
</figure>

### Organization admin
### Marketplace admin

This permission will allow managing everything in the Organization: team and user access (including their own), permissions, and the name of the Organization.
This permission will allow managing everything in the Marketplace: team and user access (including their own), permissions, and the name of the Marketplace.

>Organization administrators do **NOT** have access to transfer or delete the Organization. These actions are limited to the Organization Owner.
>Marketplace administrators do **NOT** have access to transfer or delete the Marketplace. These actions are limited to the Marketplace Owner.
### Impersonation access

These permissions are directly related to features in the API Console. Organization Administrators can control the types of OrderCloud Users that a contributing party can impersonate (act on behalf of). Without any of these turned on, the contributing party can only access the console as themselves.
These permissions are directly related to features in the API Console. Marketplace Administrators can control the types of OrderCloud Users that a contributing party can impersonate (act on behalf of). Without any of these turned on, the contributing party can only access the console as themselves.

- Impersonate Seller Users
- Impersonate Supplier Users
Expand All @@ -41,35 +41,35 @@ These are the API Roles that a contributing party has access to when using the A

## Access inheritance

The OrderCloud Portal provides the ability to create teams. A Portal team is a group of users that share a common relationship with one or more Seller Organizations. Individual Portal users can also have their own relationship with a Seller Organization. This means that a single contributing user might inherit access from multiple sources, so how does an Organization administrator know where this access is provisioned when changes need to be made?
The OrderCloud Portal provides the ability to create teams. A Portal team is a group of users that share a common relationship with one or more Marketplaces. Individual Portal users can also have their own relationship with a Marketplace. This means that a single contributing user might inherit access from multiple sources, so how does a Marketplace administrator know where this access is provisioned when changes need to be made?

### Organization contributors
### Marketplace contributors

The contributors list is a flattened view of each Portal user that has accepted access to an Organization, whether that be through a direct user assignment, teams, or both. When viewing an individual contributor, you will see exactly which relationships that user has with your Organization, followed by the "inherited" permissions and data access. This "inherited" access is an inclusive merging of settings from all of the relationships listed at the top.
The contributors list is a flattened view of each Portal user that has accepted access to a Marketplace, whether that be through a direct user assignment, teams, or both. When viewing an individual contributor, you will see exactly which relationships that user has with your Marketplace, followed by the "inherited" permissions and data access. This "inherited" access is an inclusive merging of settings from all of the relationships listed at the top.

<figure class="blog-figure">
<img src="/images/knowledge-base/inline/access-controls/org-contributor-detail.jpg" alt="Organization contributor detail view"/>
<figcaption>Individual contributor view for Example Organization. User B inherits access from a single team (Example Team) and direct user assignment.</figcaption>
<img src="/images/knowledge-base/inline/access-controls/marketplace-contributor-detail.png" alt="Marketplace contributor detail view"/>
<figcaption>Individual contributor view for Example Marketplace. User B inherits access from a single team (Example Team) and direct user assignment.</figcaption>
</figure>

Each inheritance listed provides a link to where you can view and manage (if you have permission) the Organization access controls for that specific relationship.
Each inheritance listed provides a link to where you can view and manage (if you have permission) the Marketplace access controls for that specific relationship.

#### User Access

Direct user assignments will bring you to user access. Here you create or cancel pending user invitations and manage the users who have accepted individual access to your Organization.
Direct user assignments will bring you to user access. Here you create or cancel pending user invitations and manage the users who have accepted individual access to your Marketplace.

<figure class="blog-figure">
<img src="/images/knowledge-base/inline/access-controls/org-user-access.jpg" alt="Organization user access controls"/>
<figcaption>User B's direct user access view for Example Organization.</figcaption>
<img src="/images/knowledge-base/inline/access-controls/marketplace-user-access.png" alt="Marketplace user access controls"/>
<figcaption>User B's direct user access view for Example Marketplace.</figcaption>
</figure>

#### Team Access

Team assignments will bring you to team access. Here you create or cancel pending team invitations and manage the teams that have accepted access to your Organization.
Team assignments will bring you to team access. Here you create or cancel pending team invitations and manage the teams that have accepted access to your Marketplace.

<figure class="blog-figure">
<img src="/images/knowledge-base/inline/access-controls/org-team-access.jpg" alt="Organization team access controls"/>
<figcaption>Example Teams's access view for Example Organization.</figcaption>
<img src="/images/knowledge-base/inline/access-controls/marketplace-team-access.png" alt="Marketplace team access controls"/>
<figcaption>Example Teams's access view for Example Marketplace.</figcaption>
</figure>

## Best practices
Expand Down
12 changes: 6 additions & 6 deletions content/documents/api-clients.mdx
Original file line number Diff line number Diff line change
@@ -1,23 +1,23 @@
---
type: article
title: Introduction to API Clients
description: OrderCloud uses the term API Clients to identify various access points to your organization's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid.
description: OrderCloud uses the term API Clients to identify various access points to your marketplace's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid.
author: rwatt
publishDate: 2016-06-24
updatedDate: 2018-06-25
tags: ["API Clients", "Authentication", "Integrations"]
---

OrderCloud uses the term API Clients to identify various access points to your organization's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid.
OrderCloud uses the term API Clients to identify various access points to your marketplace's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid.

## Creating API Clients
Like anything else on the OrderCloud platform, API Clients can be managed via our RESTful API. Whenever a new organization is created on OrderCloud, a default API Client is created along with a Full Access Seller user. You can use this initial context to create anything else in OrderCloud, including more API Clients.
Like anything else on the OrderCloud platform, API Clients can be managed via our RESTful API. Whenever a new marketplace is created on OrderCloud, a default API Client is created along with a Full Access Seller user. You can use this initial context to create anything else in OrderCloud, including more API Clients.

### Naming Your API Client
Choosing the right name for your API Client is important. By picking something descriptive, future developers will better understand when they should be utilized.

### Defining User Access
You can control which parties in your organization can access each of your API Clients using any combination of the following three properties:
You can control which parties in your marketplace can access each of your API Clients using any combination of the following three properties:

- `AllowSeller` - All Seller Users can use the API Client
- `AllowAnySupplier` - Supplier Users in _any_ Supplier company can use the API Client
Expand Down Expand Up @@ -46,9 +46,9 @@ This is where the `IsAnonBuyer` property comes in. When enabled, many of the Me
Read more about Anonymous Shopping <Link to="/knowledge-base/anonymous-shopping">here</Link>.

### Token Durations
Once a party has the appropriate level of access to your organization - it's important to control _how long_ that access will last. This is controlled by two properties: `AccessTokenDuration` and `RefreshTokenDuration`. The most important of the two is `AccessTokenDuration` - this is how long an `access_token` acquired using a specific API Client ID will live (in minutes).
Once a party has the appropriate level of access to your marketplace - it's important to control _how long_ that access will last. This is controlled by two properties: `AccessTokenDuration` and `RefreshTokenDuration`. The most important of the two is `AccessTokenDuration` - this is how long an `access_token` acquired using a specific API Client ID will live (in minutes).

Once the primary `access_token` expires, if the API Client is configured with a _longer lasting_ `RefreshTokenDuration`, the original OAuth response will return a corresponding `refresh_token`. This can be used to acquire a fresh `access_token` and maintain user authentication until the `refresh_token` expires. Long lasting token durations are not recommended for systems with a high level of data access in your organization as shorter token durations are more secure.
Once the primary `access_token` expires, if the API Client is configured with a _longer lasting_ `RefreshTokenDuration`, the original OAuth response will return a corresponding `refresh_token`. This can be used to acquire a fresh `access_token` and maintain user authentication until the `refresh_token` expires. Long lasting token durations are not recommended for systems with a high level of data access in your marketplace as shorter token durations are more secure.

## Using Multiple API Clients
In general, we encourage creating a new API Client for each system or isolated piece of functionality. This allows for quicker identification of bottlenecks in your solution, as every authenticated request will have the API Client that was used embedded in the `Authorization` header.
Expand Down
4 changes: 2 additions & 2 deletions content/documents/authentication.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -199,7 +199,7 @@ When logging in via `/oauth/token`, the following error codes can be returned to
| `Auth.PasswordExpired` | Based on the security profile, the password is expired | Pwd Reset |
| `Auth.InsecurePassword` | Password no longer meets requirements, and will need to be changed | Pwd Reset |
| `Auth.InsufficientRole` | One or more of the roles requested is not allowed for this user | False |
| `Auth.SellerNotActive` | The organization is inactive not accessible to login | False |
| `Auth.SellerNotActive` | The MPO is inactive not accessible to login | False |
| `Auth.UserNotActive` | User is not active, need to complete setup to activate | False |
| `Auth.LockedOut` | User is locked out due to exceeding the max attempts | False |

Expand Down Expand Up @@ -243,4 +243,4 @@ Content-Type: application/json; charset=UTF-8

## Conclusion

As you can see there are many different ways that you can obtain an access token to _give_ someone access to your organization but what about _limiting_ access within your organization? OrderCloud has a built-in way of handling access within your organization via Security Profiles which we'll talk about next.
As you can see there are many different ways that you can obtain an access token to _give_ someone access to your marketplace but what about _limiting_ access within your marketplace? OrderCloud has a built-in way of handling access within your marketplace via Security Profiles which we'll talk about next.
2 changes: 1 addition & 1 deletion content/documents/catalog-visibility-rules.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ tags: ["Catalogs", "Categories", "Products", "Personalization"]

We keep saying it: B2B is hard. Rarely is it a matter of creating a few products, giving them each one price, and opening them up for anyone to buy. There are contracts involved. Often times different buyers see different products at different prices. Sometimes different groups of users within the same buyer organization have varying levels of access to products. Sometimes these variations apply to entire categories of products.

To deal with all this complexity, OrderCloud.io makes heavy use of the concept of assignments. Allowing a buyer user to see a product typically means assigning the catalog to the buyer organization, assigning the user to some party (a user group or the entire organization), assigning that party to a category containing the product, and, finally, assigning the party to the product, which must also include a price schedule associated with that party-product relationship.
To deal with all this complexity, OrderCloud.io makes heavy use of the concept of assignments. Allowing a buyer user to see a product typically means assigning the catalog to the buyer organization, assigning the user to some party (a user group or the entire marketplace), assigning that party to a category containing the product, and, finally, assigning the party to the product, which must also include a price schedule associated with that party-product relationship.

That’s a fair amount of work, and although it gives you extremely precise control over who sees what, it’s often more control than you really need, which can make catalog management overly burdensome.

Expand Down
2 changes: 1 addition & 1 deletion content/documents/custom-password-configuration.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ The release of the new feature will be followed by an OrderCloud-wide enforcemen

## New Minimum Password Requirements

**Beginning on June 1, 2021** OrderCloud will enforce the following minimum password requirements for all users in all applications. These new requirements were applied immediately to any organization created after March 1, 2021:
**Beginning on June 1, 2021** OrderCloud will enforce the following minimum password requirements for all users in all applications. These new requirements were applied immediately to any marketplace created after March 1, 2021:

- Minimum length 10 characters
- 1 uppercase character (A-Z)
Expand Down
2 changes: 1 addition & 1 deletion content/documents/impersonation.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ tags: ["Authentication", "Impersonation Configs"]

In some instances, you may want to allow a user to order on behalf of another user. We see this use case a lot in Customer Service Desk and Call Center scenarios where customers will call their orders in and the service rep places the order on the customer's behalf. This workflow preserves the reporting data, email notifications, and presents the catalog ordering rules the buyer is configured for.

The OrderCloud API supports this capability by allowing certain users to make API calls on behalf of a buyer user, which we refer to as impersonation. If you're an admin user with the `BuyerImpersonation` role you can impersonate any buyer user under your organization as long as an applicable Impersonation Config has been created. If you're a buyer user with the `BuyerImpersonation` role you can impersonate any other buyer user within the same buyer company as long as an applicable Impersonation Config has been created.
The OrderCloud API supports this capability by allowing certain users to make API calls on behalf of a buyer user, which we refer to as impersonation. If you're an admin user with the `BuyerImpersonation` role you can impersonate any buyer user under your marketplace as long as an applicable Impersonation Config has been created. If you're a buyer user with the `BuyerImpersonation` role you can impersonate any other buyer user within the same buyer company as long as an applicable Impersonation Config has been created.

## Creating an Impersonation Config

Expand Down
2 changes: 1 addition & 1 deletion content/documents/order-checkout-integration.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ Shipping costs vary depending on vendor, product type, materials used in packagi

Promotion discounts may only apply to one item and therefore should only affect the price of that item and not the order as a whole.

A group of users within your organization may be tax exempt and arent subject to regular tax laws as your other users.
A group of users within your organization may be tax exempt and aren't subject to regular tax laws as your other users.

The Order Checkout Integration event was designed to make these calculations and estimates more customizable to better suit your business needs. With the integration event configured for your API Client, certain OrderCloud endpoints relative to the checkout process hook into predefined routes you expose in your hosted middleware application, allowing you more control over how the order total is calculated. Creating and calculating an order is normally broken down into a few steps:

Expand Down
Loading

0 comments on commit 9e5a652

Please sign in to comment.