op create user does not update Pending Invitations somehow?

Options
paulpharr
paulpharr
Community Member

we have been building out some employee facing automation using 1pass CLI

have just started sending new staff invitations using:
op create user

After setting up the provisioning group, the first invitation went out without error, but while the invited user shows up in our people list with status of invited, the invitation does not show up on the invitations tab under Pending Invitations in the web GUI

this inconsistency seems very strange & makes me think this user is in an invalid state - so hopefully everything works out - any ideas how to avoid this?


1Password Version: 1.9.0 CLI
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • ag_yaron
    ag_yaron
    1Password Alumni
    Options

    Hey @paulpharr ,

    In short, provisioning invites are not regular invites, so they don’t show up on the invite page.

    In length, the provisioning process creates a temporary user, and then when the provisioning invite email is accepted, that user is transferred over to the end user. That allows us to do some neat things around group/vault management and permission settings prior to the enduser acting on the email.

    This contrasts to the regular invite process, where a user may be invited, but until they act on the email, they have no representation in our system. Therefore no actions can be taken on that user until they act on the email and create their user.

    You can think of a regular invite as a Just-In-Time provisioning, whereas IDP based provisioning works ahead of the end user

  • paulpharr
    paulpharr
    Community Member
    Options

    is it safe to assume the user experience is the same?

    In general I prefer the provisioning invites as you describe them & i think i have seen reference in your SCIM docs - can you recommend a good place to look for a deep dive into the details?

    What i'd really like is to be able to gain more control of the process so I could invite our new employees to securely connect to our 1pass through our Slack

    I can't do this for a few reasons - you have no CLI support for slack invites & our new employees are connected to 1pass before their first day & they are still slack guest accounts

    so i'd really like to be able to create their provisioning user silently and compose my own slack messaging that allows them to accept their invitation. Any chance that's almost easy?

  • ag_yaron
    ag_yaron
    1Password Alumni
    Options

    Hey @paulpharr ,
    Sorry for the delay in response times, I'm looking into this with the SCIM team.

    Hopefully I'll have some answers soon.

  • ag_yaron
    ag_yaron
    1Password Alumni
    Options

    Hey @paulpharr ,
    Thank you for your patience.

    Slack integration is not as easy and smooth as we'd like it to be yet so there's much to improve, but here are the relevant docs on the topic:

    To be clear, CLI/Slack are invite processes discrete from the SCIM bridge. As the former do not have a ServiceAccount/Provision Manager behind them, they do not create a transfer user like provisioning.
    If you want manageable users accounts before the users actually accept their invites, you will have to go through the bridge.

  • paulpharr
    paulpharr
    Community Member
    Options

    Hi @ag_yaron

    Your April 29 answer explains how provisioning invites are not regular invites in response to my CLI question, which was very helpful in clarifying my understanding of what's going on behind the scenes

    Your May 6 update seems to contradict this - saying "CLI/Slack are invite processes discrete from the SCIM bridge"

    In my experience, users created with the CLI are behaving as you describe the provisioning process & SCIM bridge.

    So I think CLI & SCIM are using provisioning and email/slack invitations initiated using the GUI are not

  • paulpharr
    paulpharr
    Community Member
    Options

    Having posted my experience with CLI above, I'd like to report a subtle problem I am seeing using the provisioning users with the CLI

    If I create a user using the CLI, I can add them to a vault using op add user immediately, before they have accepted the invitation

    I can also add them to a vault using op add user after they have accepted the invitation and had their account confirmed

    If I try to add them to a vault using using op add user after they have accepted their invitation, but before they have been confirmed, the CLI returns an error:

    [ERROR] 2021/06/05 11:10:21 (400) Bad Request: The structure of request was invalid.

    I understand that the state of their account is different, but it would be nice if the client did not need to worry about this

    Seems like the vault could be connected to their account & they would not get access to it until they were confirmed

  • Hi @paulpharr ,

    I'm sorry for the delayed response. I am a developer on the team that works on Automated Provisioning and the SCIM bridge.

    Your observation was spot on in that the invites issued by the SCIM bridge and the CLI are similar. They follow the same process under the hood. As @ag_yaron pointed out, Slack and invites via the 1Password web client are slightly different from these.

    Thank you for your detailed steps and you are 100% correct. You can add a user to a vault before they have accepted their invite and after they have been confirmed. We intentionally do not allow a user to be added to a vault when they are in the pending confirmation state.

    This is because in the pending confirmation state the user key set which holds the encryptions keys has already been updated, but the vault access is still tied to the key set of the temporary user. Adding more access at this point would be unsafe, which is the reason why we block the clients, including the CLI, from performing this action.

    It's a good idea to try and confirm pending users as soon as possible. This is one of the reasons why the SCIM bridge checks every 5 minutes for users that are in this state and proceeds to automatically confirm them.

    The status 400 (Bad Request) error returned by the CLI in this case does not provide much clarity, and we are going to look into whether we can make the error message more descriptive to help guide users to confirm the user before adding them to a vault.

This discussion has been closed.