Users and organizations

All users in 42Crunch API Security Platform have a user account that allows them to access the platform, its services, and resources that have been allocated to them. All users are properly authenticated and their authorization checked when they log in on the platform. For auditing purposes, the actions users take on the platform are logged with their user IDs. This way, harmful user actions can be traced back to the compromised user account and the account locked to prevent any further damage.

User accounts

For businesses, 42Crunch creates a dedicated organization for the company in questions as well as an account for an organization administrator. It is the organization administrator who then onboards the rest of the users to the organization. All onboarded accounts belong to the organization of the company.

Users cannot change their username (the email address they use to log in to the platform) or the organization they belong to.

The subscription plan of the organization may impose limits to things like number of users or APIs in an organization. Organization administrators can upgrade the subscription plan at any time.

Single sign-on integration

Self-registering with a work email can be enabled, so that employees can create their accounts themselves, or it can be switched off completely. In this case, employees must either be onboarded or invited to the platform.

When SSO is enabled, employees of the company can login to the platform using their normal corporate credentials, or using 3rd-party login (for example, their GitHub or Google account) if the email is the same as in their corporate credentials. Otherwise, the login will fail.

If you are interested in integrating 42Crunch Platform with your SSO solution, or you would like to change your existing integration with us, contact our support or your 42Crunch account manager.

User roles

Permissions

The permissions are managed by organization administrators. If you need a permission you do not currently have, contact your organization administrator.

If you are an organization administrator and want to see who can do what in your organization, you can search users by permission. For more details, see Manage user permissions.

Organizations

In 42Crunch Platform, both users and resources always belong to organizations that are managed by organization administrators.

When a user account is created, it is always created in an organization. The resources (API collections and APIs) users create or import also belong to the same organization as them. Both accounts and resources can only belong to one organization that cannot be changed.

Sharing API collections is also done at the organization level: when you share an API collection, you can choose who in your organization can view or edit the APIs in it. Note that you cannot give auditors editing rights to your APIs even through sharing.

Organization administrators

Organization administrators are privileged users in their own organization. In addition to their own account, organization administrators can manage other users in their organizations, onboard the rest of the users in their company that need an account to the platform, and manage the subscription plan of their organization.

To manage users, organization administrators can:

• Add or delete user accounts in their organization
• See which APIs and API collections each user owns
• Change user roles, such as promote new organization administrators
• Force password reset for a user account
• Lock a user account that shows suspicious or harmful activity

Organization administrators can see how many collections and APIs each user in their organization has. Organization administrators can also manage all API collections in their organization, and create a scan configuration and run Conformance Scan on premises on any APIs in their organization.

Organization administrators have access to view and modify all API collections in their organization. This means that all API collections in an organization are visible to all organization administrators like the collections were their own, both on the API Collections page and in the monitoring dashboards. If an organization has several API collections, we recommend using more descriptive collection names that just organization and company name to be able to tell all collections apart.

To avoid losing things like APIs and API collections, tags and tag categories, customization rules and security quality gates (SQGs), when organization administrators delete a user account, they must first transfer the assets related to that user account to someone else before the account can be deleted. If the deleted user was a team lead in any teams, those roles are also transferred to the new owner of the assets.

To ensure that an organization always has at least one organization administrator, organization administrators cannot lock or delete their own account, nor can they remove their administrative rights. However, they can still do this to other organization administrators in their organization.

Invitations

By default, new users are either added when they self-register to the platform, or when organization administrators manually create accounts for them. But there is a third way: with user invitations, organization administrators can invite people to join their organization.

When you invite users to join your organization, you predefine some settings for their user accounts, such as permissions, and whether they are organization administrators, just like when you manually create an account. When a user follows the invitation to log in to the platform, the user account is created in your organization.

There are two ways to invite people to your organization:

• Email: An invitation mail with a client token is send to the email address of your user. This saves you the trouble of having to send a notification mail with the account details yourself. The email address also becomes the username of that user, because the client token is only valid for that email. This is the default and more secure option.
• Link: An invitation link with a client token is generated and you can copy and share it to your user as you want. Anyone with a valid invitation link can log in to the platform, so be mindful how you share the link.

You can choose if you want to allow both invitation methods. Both invitation mails and links expire after a specified time. For invitation mails, you can choose the expiration time from five minutes to a week. Invitation links always expire after 15 minutes.

Mail invitations can be combined with Single sign-on integration, and there are multiple options on how that can be done:

• The invitations can be restricted to only email addresses that are outside your SSO domains. Users in your SSO domain cannot be invited to join your organization but must self-register or be created manually.
• The invitations can be restricted to only email addresses within your SSO domains. Users outside your SSO domain cannot be invited to join your organization but must be created manually.
• Anyone can be invited to join your organization, regardless of the domain of their email address.

For invitation links in SSO, you must select which SSO domain the link applies to. Only users from that particular email domain can register through the invitation link.

User invitations are switched off by default, and you cannot change the settings for invitation method yourself. If you would like to enable this feature in your organization or change its settings, contact 42Crunch support and let us know what kind of configuration (invitation mails or links, SSO or not) you would like to have.

Adding user accounts manually still has its place, too. For example, if you need to add an account that a service can use to access 42Crunch Platform, you must do that manually, because there is no recipient to complete the account creation. User accounts for the auditor role must always be added manually, they cannot be invited to join.

Teams

Users in an organization are grouped into teams that have access to API collections shared with them. By default, each organization always has a team that includes everyone in that organization, and more teams can be added as needed for specific groups of users.

For these additional teams, there are two ways how to manage them:

• By default, organization administrators are the ones creating and managing teams in their organization. Once they have created a team, they can assign a team leader for it, who can then add or remove more users to it as needed, but cannot change the name of the team or the team leader. Team members can view who is in their teams, but cannot edit the team in any way.

  

• Organization administrators can choose to grant regular users a permission to manage teams. In this case, the user with this permission can create new teams and delete existing ones, as well as manage team members — including team leaders — in any team in the organization.

  If you have APIs in 42Crunch Platform that should only be shared on a need-to-know basis and you have set up dedicated teams for sharing these APIs, consider carefully if you want to grant the permission to manage teams to any regular users.

In both cases, organization administrators always have full control over all teams in their organization and their composition.

Sharing APIs to teams

In addition to sharing API collections with individual users, collections can also be shared with whole teams at one go. When you share an API collection, you can choose which team or users you want to share it with. You can also give different access rights to your collection for different groups, or even to different users in a team.

Removing a team from the organization does not delete the user accounts of the team members, but it does remove their access to API collections shared with that specific team.

System preferences

System preferences (organization settings) allow organization administrators to control certain high-level options throughout their organization to change or add to the default settings in 42Crunch Platform. For example:

• Organization administrators can define a custom message banner that is shown at the top of the platform landing page to all users in their organization. See Add a message banner on the landing page.
• Organization administrators can switch the RSS feed on the platform landing page on or off. See Manage the RSS feed.
• Apart from some basic limitations like maximum length and reserved characters, the names for APIs and API collections do not have defined naming conventions. Organizations can specify a regular expression that all APIs imported and API collections created in the organization must follow. The specified naming conventions are applied in addition to the basic limitations already imposed by the platform. See Define a naming convention for APIs and Define a naming convention for API collections

This way you can easily impose restrictions or conventions stricter than the default behavior to suit your organization's needs.

Platform audit logs

As part of its operation, 42Crunch Platform creates audit logs on the activity in the platform to create an audit trail. The audit logs are separated from other logs and record, for example:

• What happened?
• When it happened?
• Who performed the action?
• What was the target of the action?

Platform audit logs are generated per organization, and organization administrators can view the activity in their particular organization in platform audit logs. You can see actions in your organization, which user performed which action, and when those happened.

The authentication type column also gives you an idea where the action originated from:

• Cookie: These actions were triggered by authenticated users interacting with the platform UI, or from scripts that use cookie for authentication (and not API key).
• API key: These actions were triggered by API calls, for example, from the integration plugins (like CI/CD or IDE) or from scripts.

Platform audit logs are intended as a diagnostic tool, not a detection tool. The logs are not real-time, there is a delay of one minute before you can see the events when you refresh the log page. Platform audit logs are for gathering information: for example, if you become aware of a compromised API key, you can then use platform audit logs to drill down to the activity in your organization to check if that API key has been used to perform an action and when was the last time it was used. If you click on an event, you can view more details on it, such as the name of the API key that was used, listed in the Session ID field (here token_auth).

Platform audit logs can also be exported as JSON, for example, for reporting purposes.

Platform audit logs are provided on activity over the last three months. For security reasons, regular users cannot view platform audit logs.

Currently, only the events from the last 24 hours are visible on the UI. This will be improved on in a later release.

Platform URL

If you are not sure what your platform URL is, contact our support.