Teams, roles and sign-in

Everybody who signs in to a business holds one role there. It decides what they can do in the dashboard, whether they can make API keys, and what they can let a connected app do.

How a key or a token is sent, and what each scope allows on the API, is Authentication. This page is the people side.

More than one business

One sign-in can belong to several businesses, each with its own templates, documents, team, plan and bill. Add a business, in the account menu, starts another that you own and switches you to it; an invitation from another business to your address adds that one. The business menu at the top moves between them. A sign-in can start up to ten; ask us if you need more.

Roles

A business has one owner, the person who made it. Ownership is transferred, never given: only the owner can hand it over, and becomes an admin in doing so. Everybody else is an admin, a manager, staff or a viewer. Each role starts with these permissions, and the owner's cannot be changed.

Some things go by role and cannot be given to anybody else: only the owner closes the business, and only the owner or an admin changes its details or its billing, or exports its records.

Managing the team

Whoever holds team.manage invites people, changes their roles and removes them. Under Team, Permissions on a member's row also grants or withholds any one permission for that person, whatever their role says; changing their role clears those. Three rules hold throughout:

• Nobody reaches above themselves. Nobody invites somebody as, or gives them, a role above their own, or changes, removes or edits the permissions of somebody above them. An admin is made by the owner or an admin.
• Nobody gives what they do not hold. A permission you lack cannot be granted, even by clearing a refusal the role would answer yes to.
• Nobody acts on themselves or the owner. You cannot change your own role or permissions, or remove yourself: you leave. The owner can neither leave nor be removed until they hand the business over.

An invitation names an address and a role. Its link works for seven days, and only for somebody signed in as that address. Inviting the address again replaces it.

API keys

Making and revoking keys, test keys included, needs signing.api: the permission behind webhooks, tablets, booking-system connections and connected apps too. Integrations → API keys is in the menu for owners and admins; anybody else given the permission finds it at https://app.signsealer.com/keys.

A key is the business's, not the person's, and its scopes are not limited to what its maker may do: whoever holds signing.api can make a key with any scope on the form. Give that permission only to somebody you would trust with all of them.

The form offers signing:read, signing:write, signing:templates, signing:workflows, signing:subjects, signing:webhooks and signing:devices, and an expiry of never, 30 days, 90 days or a year. The four parts of signing:write (signing:send, signing:remind, signing:links, signing:void) are not on it: only a connected app's tokens hold them.

Connected apps

The person pressing Connect on the consent screen must hold signing.api, so a manager, staff member or viewer is refused unless it was given to them. Each scope asked for is then checked against that person, and one they could not give is left out of the grant. If none is left, the connection is refused.

With the defaults this matters only once somebody's permissions change: a manager given signing.api can give an app everything but signing:templates, and an admin whose voiding is withheld cannot give signing:write or signing:void.

An app holds one grant per business. Connecting it again replaces the grant, which becomes the grant of whoever connected it this time. Giving less cuts the access tokens it already holds down at once, and revokes any left with nothing; giving more changes no token already issued. An AI assistant whose registration or metadata document does not list refresh_token in grant_types is given no refresh token. Each access token shows under Integrations → API keys, under the app's name.

When somebody leaves

Keys are left alone on purpose: one is what the booking form or the till runs on. But the person saw its secret, so after a removal the Team page says how many keys they made that still work, and after a role or permission change how many can now do more than the person may. Revoke any they should not keep under Integrations → API keys. A removal also says how many tablets they set up and systems they connected still work, which they may still have in hand. A pairing code is only good while whoever made it could add a tablet, so one nobody has typed in yet stops when they go.

Single sign-on with SAML

A business can make its own identity provider, anything that speaks SAML 2.0, the only way in for everybody at its email domain. Whoever holds team.manage sets it up at https://app.signsealer.com/settings/sso.

There is no metadata file: type these in. The assertion itself must be signed, must name that entity ID as its audience, and must carry an email address, as the Name ID or an email, mail or emailaddress attribute.

1. Prove the domain. Publish the TXT record the screen shows at _signsealer.<domain>. Its value is the token alone, with no signsealer-verify= in front as a signing domain's has. We look for it every five minutes, and until a look finds it the screen says what the last one saw. A proven domain is not looked at again. Claiming the domain again before then gives it a new token, and only the new one counts. A domain belongs to one business, and only that exact domain counts: acme.com does not cover an address at uk.acme.com.
2. Connect the provider: its entity ID, https sign-in URL and signing certificate. Assertions are checked against this certificate and no other. To rotate it, save the connection again with the same entity ID.
3. Require it. This is refused until a domain is proven, a connection is on, and the owner is named as the one person who keeps the ordinary way in, so an outage at your provider cannot lock the business out.

Once it is required

• Somebody at a proven domain who types their address on the sign-in page is sent to your provider. The emailed link, Google, Apple, passkeys and texted codes are refused for them, and a session opened another way ends on its next request. The named owner is the exception.
• It follows the address, not the business: somebody at your domain signs in through your provider for every SignSealer business they belong to. Other domains sign in as before.
• It works only while required, so it cannot be tried first. Try it the moment you switch it on, while the owner can still sign in and switch it off.
• The sign-in must start at SignSealer and finish in the same browser within ten minutes. One started from your provider's own list of apps is refused.
• API keys and connected apps are not sign-ins, and carry on.

Somebody new is given a viewer's seat, joined to any account they already had at that address: your provider says who somebody is, never what they may do. To start somebody higher, invite them before their first sign-in; accepting sets the role. A member who was removed, or left, is refused and told to ask for an invitation. Removing somebody from your provider stops their next sign-in but not a session already open, which ends after twelve hours idle or thirty days; and nothing tells SignSealer, so they stay a member, with whatever they connected, until you remove them under Team.

What the activity log records

Activity needs audit.read. Each line shows when, who, what, about which record, any reason given, and the network it came from. The other details below are kept in the record and the business's export. It can be searched by action name.