How sign-in decisions work: the policy engine

Every time someone opens an application, the SSOGEN sign-in decision policy engine makes one decision: may this person open this application now, and what must they still do first? It checks the parts in a fixed order, and when it cannot establish a fact it fails closed. This guide explains the parts that feed that decision, in the order SSOGEN uses them, so that the rest of the policy guides make sense. No earlier knowledge is assumed.

The example company is Acme Corp (domain acme.example). Maria Lopez works in finance and opens the application “Acme Payroll”.

The parts, in plain words

Term	What it means
Identity provider	The system that checks who somebody is: your company directory (LDAP), a SAML or OpenID Connect provider such as Entra ID or Okta, or SSOGEN’s own usernames and passwords. You add them under SSO policies > Identity providers.
First factor and second factor	How a policy asks people to prove who they are. The first factor is the way they sign in: a password, single sign-on at a provider, an emailed sign-in link, phone approval or a passkey. The second factor is an extra proof after it: none, required (an authenticator approval or code, a recovery code, or a weaker text or email code), or a passkey or security key only.
Sign-in strength	How strongly the person has proved who they are, as a result. SSOGEN uses three steps, below. Rules and What if read it.
Policy (the console says authentication policy)	A named set of requirements that many applications share: which first factors and identity providers may be used, whether a second factor is required, how recently the person must have signed in, and what happens when more is needed. You edit it once and every application using it follows.
Rule	One “when this is true, then do that” line. Rules are checked top to bottom, and the first rule that matches decides.
Access rules	One list of rules for the whole organization. They decide what people may reach once they have signed in, for every application.
Default policy	The policy used by every application that has no policy of its own, and by signing in to My Apps.
Admin Console policy	The policy that decides who may sign in to the Admin Console. It never falls back to the default policy.

SSOGEN also has a deterministic sign-in risk score from 0 to 100 and a rule can read the score and ask for a second factor only when a sign-in looks risky. See The sign-in risk score.

A policy’s first and second factor add up to one of three strengths. A passkey sign-in counts as both factors on its own. The console uses these exact words wherever a rule or a test names a strength:

Strength	What it means
Password or single sign-on	Whatever the identity provider did is accepted.
Plus a second factor	A second factor is required. SSOGEN asks for one when the provider did not.
Passkey or security key	Only a passkey or security key is accepted. Passkey sign-in must be offered.

A provider that does multi-factor authentication of its own and says so (Entra ID and Okta usually do) meets Plus a second factor without SSOGEN asking again.

A passkey is a sign-in method built into a phone, a laptop or a hardware security key. It cannot be typed into a fake website, which is why it is the strongest step.

When Maria opens “Acme Payroll”, SSOGEN works through these questions. The first one that fails ends the decision with a refusal.

Is she assigned to the application? Directly, or through a group she belongs to (an application with Assignment required switched off is open to every active person). Being assigned is never granted by signing in more strongly.
Is the application ready? It must be switched on and, if it uses an App Pack, the pack must be active.
Does the application’s policy allow any provider at all? A policy with no providers refuses everybody.
The access rules, if you have saved any. The first matching rule decides: allow, deny, and the other outcomes described in Rules and conditions.
The application’s policy rules (called Conditions on the policy), if it has any. Again the first matching rule decides.
Is the session strong enough, recent enough, and from an allowed provider? If Maria signed in at Corporate LDAP with only a password and the policy needs Plus a second factor, she is not refused: she is sent to prove more (see below). If the provider is not one the policy allows, she is refused.

The What if page shows this exact chain for any person and application, rule by rule.

When more is needed (step-up)

If Maria’s sign-in is weaker than the policy requires, SSOGEN asks for more instead of refusing. The policy’s When more is needed setting says where she is sent:

Choice	What happens
SSOGEN second factor	SSOGEN asks for an authenticator code or a passkey after the provider.
The identity provider	She is sent back to her provider to prove more.
Either	SSOGEN offers its own second factor or the provider’s, whichever she can do.

The policy can also list Alternatives, in order: if the first way is not available to her, the next is offered.

Fail closed when a fact is missing

SSOGEN never guesses toward “yes”. If a rule list cannot be read, or a rule names a group or a network that no longer exists, or a fact the rule needs is not known, the decision is a refusal until somebody fixes the rule. The rule editor shows such a name as “a group that no longer exists” so you can find it.

Which policy applies to an application

An application with its own policy uses that one.
An application with none uses the default policy (set under SSO policies > Defaults).
If there is no default either, the application cannot be opened, and the application wizard will not let you activate it until a policy exists.

The Admin Console has its own setting, Admin Console, on the same Defaults page. It decides which providers may hold a session in the console and never falls back to the default policy. A new installation sets up both: Default sign-in for My Apps and Administrator sign-in (a password plus an approval in the SSOGEN Authenticator, its code or a recovery code, passkeys allowed) for the console. The console’s policy is the only rule for opening the console, and it always asks for a second factor. See Defaults and monitoring a new rules version.

Where each part lives in the console

Menu item (under SSO policies)	Use it to
Identity providers	Add and test the systems that check who somebody is.
Policies	Create, edit, test, duplicate and delete policies. See Create a policy.
Defaults	Choose the default policy and the console policy, edit the access rules, and monitor a new rules version.
What if	Ask what would happen to a person opening an application, without changing anything.
Network zones	Name groups of IP addresses (“the office”) that rules can use. See Network zones.

The Access rules tab of an application chooses its policy.

A worked picture

Acme has two policies and one set of access rules:

Corporate LDAP: first factor password at Corporate LDAP, second factor None (strength Password or single sign-on). This is the default policy.
Finance with second factor: first factor password at Corporate LDAP, second factor Required (strength Plus a second factor), used by “Acme Payroll”.
Access rules: rule 1 allows the group “Employees”, and “When no rule matches” is Deny.

Maria (in the group Employees) opens “Acme Payroll”. She is assigned, so step 1 passes. The access rules match her “Employees” rule and allow her. The policy “Finance with second factor” has no conditions. She signed in with only a password, so step 6 sends her to enter an authenticator code. Once she does, Payroll opens.

A contractor who is assigned to Payroll but is not in “Employees” matches no access rule, so the default Deny refuses them at step 4.