Skip to content
lagstyr.Register interest

The Lagstyr handbook

  1. For the person who decides
  2. What Lagstyr is for you
  3. Reading your console
  4. What needs your attention
  5. Deciding a proposal
  6. After the decision
  7. Operating the work
  8. Agents and their runs
  9. Governing the company
  10. Access, people and language
  11. For the person who administers
  12. Administering your console
  13. Bringing an agent into service
  14. Defining and promoting action classes
  15. Registering AI systems
  16. Emergency access, passwords and sessions
  17. Sources, structure and the operations index
  18. What this installation connects to
  19. For engineering and DevSecOps
  20. Planning an installation
  21. Installing Lagstyr
  22. Securing your installation
  23. Building and commissioning integrations
  24. Commissioning agents and retrieval
  25. Monitoring and routine operations
  26. Upgrading and managing releases
  27. Backups, restoration and recovery
  28. Responding to incidents
  29. Reference
  30. Glossary

Documentation · The Lagstyr handbook

Emergency access, passwords and sessions

Normal access to your console uses your organisation’s identity provider. Everything in this chapter is for the cases where that is not enough.

Emergency access

The sign-in page carries one line about it: Emergency access requires an armed, two-person host ceremony and an incident id. The console cannot arm it. The person who operates your host does that, on the box, for a named incident, and until they have, the console answers Emergency access is not armed for this incident.

The form itself is three fields: the incident identifier, your email address and your password. The page says what you are getting: This route is audited, short-lived and single-use. Normal access uses enterprise SSO. The console allows ten attempts a minute from one source, and refuses further ones with Too many attempts. Try again later. That limit is per source, so an attacker cannot use it to lock the emergency door against you during the identity-provider outage it exists for.

An emergency session costs you something on every governed form. Where a federated session proves itself silently, an emergency session asks for your password again on each proposal and each decision, and the fresh sign-in that a federated session would be sent through is not available to it: Emergency sessions continue to use the configured local password ceremony for decisions.

Setting your own password

A password that was set for you can be used once. The first time you sign in with it through the emergency route, the console takes you to Set a new password and nowhere else; there is deliberately no way to skip it. You enter the password you were given and a new one of at least fifteen characters, and the account being changed is shown on the page but never taken from the form.

The window for this is a one-time ticket that the emergency sign-in mints. It is spent only when the new password is accepted, so a mistyped password costs you nothing, and if you leave the page and come back later you will be told to Start again from the emergency login: the rotation window has closed. Too many attempts on one account are refused for fifteen minutes. On success you land on the sign-in page with Password set. Log in with your new password.

The two clocks on a session

Your account menu states them: This session idles out after 15 minutes without activity, and ends after 8 hours regardless. The long forms, action classes and AI systems among them, repeat the first clock at the top of the page because a form abandoned past it is submitted into a sign-in page. The number the console shows is held equal to the number the kernel enforces by a test, so the console never promises a longer session than it can keep.

Ending every session

Log out ends this session. Log out everywhere asks End every session for this operator, on every device? and then revokes them all. Use it when a device is lost or a credential may have travelled.

What the administrators page records

Administrators shows who can use the console at all, with each person’s roles, where their attributes came from, their active sessions and their last sign-in, and beneath that a trail of recent authentication and administrative events, including any emergency sign-in. The same page carries the approval-route readiness card, because who holds authority and is every selected act still backed by an effective route, grant, mandate and role are two halves of one question. The two-person review recorded on this page is described in Access, people and language.

Previous chapter Next chapter
lagstyr.
ContactSecurityPrivacyTerms