ores.iam.registration_policy_messages

1. Includes
2. Messages
- 2.1. registration_policy_request
  - 2.1.1. hostname
- 2.2. registration_policy_response

The registration policy protocol messages.

The door asks one question before it offers a form, and this read answers it: whether the deployment accepts registrations, whether one also waits on an approval step, the tenant the registration lands in, the party and role the new account receives, and whether the result is usable at once. The policy itself is settled in registration and onboarding defaults, and the interactions that read it are the entry journeys.

The read needs no session, because the screen that shows the form is the one a person who is not in the deployment yet is looking at. It is separate from iam.v1.ops.bootstrap_status: one answers whether the deployment has been set up, the other what it offers a person who is not in it, and they change for different reasons.

The address the request arrived at names the tenant. A client states the hostname it was served at, and the service resolves the tenant from it, falling back to the tenant flagged is_registration_default only when the address names none.

1. Includes

#include <string>

2. Messages

2.1. registration_policy_request

2.1.1. hostname

/**
 * @brief The address the door was served at.
 *
 * The tenant is resolved from it. When it names no tenant, the tenant
 * flagged @c is_registration_default is used, and when the deployment
 * nominates no default either, the read refuses with
 * @c no_registration_destination rather than naming the system tenant.
 */

2.2. registration_policy_response

2.2.1. success

2.2.2. message

2.2.3. error_code

/**
 * @brief The stable code a client branches on.
 *
 * Empty when the read answered. @c signup_disabled and
 * @c signup_requires_authorization mean the deployment refuses the form;
 * @c no_registration_destination means it accepts registrations but has not
 * said where they land. @c no_default_role means it has not said what a new
 * account may do. Each names a different thing for an administrator to fix,
 * so a screen states the reason rather than one closed door.
 */

2.2.4. signups_enabled

/**
 * @brief Whether the deployment accepts registrations at all.
 *
 * The setting @c system.user_signups, read at system scope: it is the
 * deployment's answer rather than a tenant's, because the person who opens
 * the door is not the person who decides what it opens onto.
 */

2.2.5. authorization_required

/**
 * @brief Whether a registration also waits on an approval step.
 *
 * The setting @c system.signup_requires_authorization. No approval workflow
 * exists yet, so the honest answer is that a deployment which sets this
 * refuses registrations and says why.
 */

2.2.6. tenant_id

2.2.7. tenant_name

2.2.8. party_id

/**
 * @brief The party a new account joins, when the tenant nominates one.
 *
 * Empty when the tenant nominates none. A registration into a tenant with
 * no nominated party creates a pending account rather than failing.
 */

2.2.9. party_name

2.2.10. role_id

/**
 * @brief The role a new account receives.
 *
 * Empty when the tenant nominates none, which closes registration: an
 * account that holds nothing is not an account somebody can use.
 */

2.2.11. role_name

2.2.12. usable_now

/**
 * @brief Whether a registration can sign in without an administrator.
 *
 * True when the destination names a tenant, a party and a role, because an
 * account needs all three to sign in. False means the account is created
 * pending and waits for an administrator to finish setting it up.
 */