Users

The Users page shows all the users on your team.

The available actions are:

• Invite a new user.
• Resend an invite to a user.
• View and edit a user's details.
• Delete a user.

Tip: You can perform all access management actions with the Account Management API.

User groups

All users belong to at least one group, and that group gives the user access permissions. By default, Device Management has two groups:

• Administrators: Can access all Portal and services features. Administrators are the only ones who can use the features of Access Management, Team Configuration, Billing and security-related actions such as uploading certificates. Administrators also have to accept legal agreements on behalf of their teams; Developers cannot accept agreements, not even on their own behalf.

• Developers: Can access all Portal features except the administrator actions listed above.

  Note: A user without a group defaults to the permissions of the Developer group.

You can also create your own groups with specific access policies to help you manage secure device access (SDA). In the context of SDA, a user is likely to belong to more than one group; there is no need to remove a user from the Developers or Administrators group to give them SDA permissions. This topic is covered in the SDA chapter.

Inviting a new user

To invite a new user:

1. In Access Management > Users, click Invite New User.

   The Invite User pop-up opens.

2. Enter an email address.

3. Choose an identity provider. The options are:

   • Native: The user needs to create a Portal password to log in.
   • mbed.com: The user can use their existing Mbed password to log in.
   • Custom provider: The user does not need a Portal or Mbed account. Instead, the user can log in with a custom identity provider, such as Google. Please ensure the email address you entered above is associated with the correct custom provider; you cannot change an existing user's email address.

   Note: You can define identity providers in Portal (but not through the Invite user pop-up), and some may already be available to your team. Alternatively, contact your account administrator. For more information, see the Team identity provider section.

4. Choose a group as explained in the User groups section.

   Alternatively, if you don't choose a group, the user’s permissions will be based on the Developers group.

   You do not need to choose a team; the user is associated with your own team. If you belong to more than one team, the user will be associated with the team you are logged in with.

5. Click Invite.

6. An invite is sent to the user's email address.

   The invite email includes an activation link. When the user clicks the link, the user is taken to Portal to complete signing in, and you are notified by email.

Resending an invite

You can send the invite again if the user has not accepted the original invite and it expired (the user will have received an email notifying them that the invitation expired). You cannot resend an invite if the user had already accepted the original invite, and you cannot send the invite to a different email (you will have to create a new user if you need to use a new email).

To resend an invite to a user who hasn't accepted the original invite:

1. In Access Management > Users, select the user from the list.

   You can select more than one user, but the action is only available if none of the users you've selected have accepted their invite.

2. Click Actions > Resend invite.

   The invite is sent to the same email as the original invite.

Editing user details

To view and edit user details:

1. In Access Management > Users, click the user's name.

2. The User Details pane opens.

   You cannot edit details for multiple users at once.

The pane has five tabs:

• Summary: Basic user information, including date of last activity. You cannot edit these, but users can edit their own information through their profile settings.

• Groups: A list of all the groups the user belongs to.

  Available action: remove from group (but you cannot associate users with a group from the Users page - you must edit the group itself. See Groups).

  If you remove a user from a group, the permissions the user got from the group are instantly revoked (the user does not need to log in again for their permissions to be checked). If a user is relying on those permissions for their work and does not have them from any other group they belong to, they will not be able to work.

• Security: The user's identity provider.

  Available actions:

  • Add and remove identity provider options. If you change an existing user's identity provider, the user will not get a new invite email; they can just log in with the new IdP.

  You can change your own identity provider, but we strongly recommend that you keep your account as a native Device Management or Mbed.com account, so you can log in even if there are problems with your IdP.

  • Reset password. The user receives a reset link email. The current password is no longer usable, but if the user is logged in, their session won't be closed. This option only affects users with a native Device Management account or an Mbed.com account; you cannot force a password reset for users with a custom IdP.

• Active sessions: Session information, including IP address. This tab is only visible while the user has active sessions (where "active" means the user is currently logged into Portal), and does not display session history.

• Attributes: Full user information as returned by the API. Not editable.

Adding an existing user to a new team or tenant

If you administer multiple teams or tenants, you can add any user to any of those teams. (There is no limit on how many teams a user can join.)

To invite an existing user to another team, log in to that team's account and invite the user. The process is identical to creating a new user as explained above, but instead of an invite with an activation email, the user receives an email with details about the new team.

Tip: If you're an aggregator creating a tenant team, you can create an administrator for that tenant as part of the team creation process.

Deleting a user

Deleting a user revokes the user's access rights entirely. Do this if you are suspicious of the user's activity, if the user has left your company, if you have reason to believe the user credentials have been hacked or for any other security concern.

You can invite back a deleted user with the same email address. The user is new, however, and you have to restore their group associations, permissions and so on.

When you delete a user who is currently logged in to Portal, the session ends – the user cannot continue work.

When you delete users, their API keys are deactivated and no longer show as having an owner. You have to set a new owner before you can reactivate the key. Also notice that the API keys are deprecated, use application access keys instead.