Organization sign-in policy

Open Administration → Sign-In Policy to inspect the current organization’s policy, review an exact enrolled SSO session and explicitly configure its requirement. The policy applies across Test and Live. Environment resets do not reset it.

Katara must first enroll the enterprise connection and its authentication profile. This page does not set up a provider or collect upstream claims. An unavailable service or denied read remains unavailable; the portal does not fabricate a policy or session.

Sign in through your organization

When the sign-in service offers enterprise sign-in, the sign-in page has a Continue with Your Organization entry. An administrator shares a link to it that names the organization, /login?organization=<organization ID>, or a person types the organization ID. The page asks GET /katara/v1/sign-in/organizations/{org_id} which identity providers the organization’s enrolled connections use and sends the browser to its identity provider; with more than one, the person picks. That lookup needs no session and carries no authority: an organization without enterprise sign-in answers the same empty list as one that does not exist, and the callback still checks the enrolled connection, the person’s mapped identity and current membership.

A person signs in this way once their identity is mapped to their account, which directory provisioning does when it creates or updates them. Email alone never links an identity to an account.

Review SSO and local verification separately

Choose Review Current SSO Session to read metadata for the current canonical app session. The response contains its exact connection reference, profile integrity, configured issuer, enrolled maximum authentication age and effective authentication/expiry timestamps. It excludes upstream subjects, client identifiers, tokens, claims and private identity-service session identifiers.

The public reviewed_session_id is an app-session metadata identifier. It is not a credential. Saved review metadata is not proof of current validity: policy configuration rechecks the same-user session, profile, current authority and authentication age.

Local sensitive-action verification is independent. SSO authentication time does not establish password, email credential or local MFA freshness. Complete the required local verification and refresh the policy page. If an existing policy requires SSO, verification must preserve valid SSO ancestry; an unrelated password session does not automatically inherit SSO access.

Choose a whole maximum authentication age from 1 second through the selected profile’s enrolled maximum, at most 86,400 seconds. The server checks that the reviewed SSO authentication is recent enough for the requested limit. Explicitly choose whether the reviewed profile is required, review the exact current policy revision, then confirm. Disabling the requirement still requires the same reviewed SSO and fresh local authority checks.

Rotate to a new enrolled profile

Keep a session that satisfies the current policy open. Sign in to the newly enrolled profile in a separate browser profile or device. Its Account Security page shows that signed-in app session’s Current Session ID. A single browser cookie jar may replace the old sign-in; the policy page does not automatically preserve two sessions.

In the old-policy-authorized session, enter that exact replacement app-session ID and choose Review Exact Replacement Session. The owner must have independent fresh local proof. The server returns only live SSO evidence for the same user and organization. It does not enumerate sessions or expose another user’s evidence. A new-profile session cannot bypass the old policy to inspect the organization.

Reviewing the replacement does not change the policy. Confirming a new policy requires the exact returned connection/profile pins and app-session ID, the current policy revision, the chosen age, and fresh owner authority. The server checks all of them again atomically.

SDK and HTTP

The five human-session endpoints are scoped directly to /katara/v1/orgs/{org_id}:

Method and path	Result
GET /session-policy	{org_id, policy}; policy can be null
GET /session-evidence	{org_id, evidence} for the current app session
GET /session-evidence/{session_id}	Explicit same-user target review under current owner policy authority and fresh local proof
POST /session-policy	Historical completed operation receipt
GET /session-policy/operations	Bounded organization-wide metadata audit

All replies use Cache-Control: no-store. API keys, service identities and workloads cannot use these human-session endpoints. Current policy/evidence reads require organization read authority; policy changes and target-session review require owner authority. The audit requires current locus:audit:read authority.

const current = await client.organizationSessions.policy(org_id);
const reviewed = await client.organizationSessions.evidence(org_id);
if (!reviewed.evidence) throw new Error('Review an enrolled SSO session first.');

// Only after independent local verification and explicit human review:
const operation = await client.organizationSessions.configure(org_id, {
  reviewed_session_id: reviewed.evidence.reviewed_session_id,
  expected_revision: current.policy?.revision ?? 0,
  connection: reviewed.evidence.connection,
  profile_integrity: reviewed.evidence.profile_integrity,
  max_authentication_age_seconds: reviewedMaximumAgeSeconds,
  required: reviewedRequirement,
}, originalRequestKey);

TypeScript exposes organizationSessions.policy, evidence, reviewSession, configure and operations. Python exposes organization_sessions.policy, evidence, review_session, configure and operations with the same metadata fields. Neither SDK retries configuration automatically.

Recover an unknown result

Preserve the exact metadata request and original idempotency key if a response is lost. The portal retains only the account, organization, exact metadata pins, request digest and key in tab storage, along with separately reviewed safe SSO metadata. It does not store credentials or upstream claims.

After signing back into the same account, explicitly review and retry the original request. A later refusal does not discard it or permit a replacement key. The server can return the original completed operation under current authority without applying another policy revision. Such a receipt is historical: read the current policy separately to learn what is enforced now.

The policy audit contains only completed operation ID, actor ID, organization ID and creation time. Pagination defaults to 25 and permits 1–50 entries. Pass next_before and next_id together as the next request’s before and before_id. These are exact timestamp/UUID boundaries, not environment or reset cursors. Audit entries do not expose policy bodies or private SSO provenance.

When enterprise sign-in is not enabled

Katara enrolls each enterprise connection and its session profiles; nothing in this API or the portal creates one. Until enterprise sign-in is enabled for the deployment, the five policy endpoints answer 501 with feature_unavailable, and the organization lookup does the same and asks the person to sign in with their Katara account. Once enabled, every request still checks the exact enrolled connection, whether it has been retired, and current authority.