Tier access by location

The same person works in the office, from home without a VPN, at a customer's site, and on the road. With a sign-in policy, simple sign-in applies to data access in the corporate network, and a code is additionally required from outside—without a second configuration and without a second program. Administration, on the other hand, always requires the code, even in the office.

The service distinguishes locations solely by the origin of a request (network address; behind a trusted proxy, the forwarded address) and the sign-in method; the sign-in policy combines the two. All locations reach the service over HTTPS: the unencrypted HTTP port responds only on the server itself (see HTTPS and certificate).

Why administration always requires a code. Administration can change people, keys, and rules, and thus every other access. That's why the fixed lower bound Gateway:Store:RequireAdminTotp (default true) applies to it: a code for every sign-in method and every origin. An exception for the corporate network in a sign-in rule doesn't change this. The lower bound can be turned off only in the server's configuration file (see Configuration); this isn't recommended.

1. Set up HTTPS with a certificate the clients trust; see HTTPS and certificate. If there's a proxy in front of the service, register it as trusted; otherwise every caller with the proxy's address would count as „inside“.

2. First have every person who is to work from outside set up their second factor; see „Set up or reset the second factor“ (documentation of the administration app).

   Keep to the order. If the code requirement for data (step 3) already applies before a person has their factor, the service refuses them from outside with 403 as soon as their enrollment period (TotpEnrolHours, default 24 hours) has expired. In the corporate network, they continue to work.

3. In the administration app, open Anmelderichtlinie (Sign-in policy), tab Anmelderegeln (Sign-in rules), and create the rule for data access, with your corporate network as the exception (except_from, here 10.0.0.0/8); see „Set the sign-in policy“ (documentation of the administration app):

   Rule	Area	Method	Effect	Exception
   Data with personal key from outside only with a code	Data	PersonalKey	RequireTotp	10.0.0.0/8
   SQL Server logins only in the corporate network (optional)	All	SqlLogin	Deny	10.0.0.0/8

   Leave the rule „Verwaltung nur mit zweitem Faktor“ (Administration only with a second factor) (area Admin), which every new store starts with, unchanged; the lower bound requires the code there anyway.

4. For a presentation at a customer's site, issue a key of its own instead of passing on a personal one: read-only and exempt from the second factor. In the administration app, this is an on-demand key „Präsentation“ (Presentation) that's activated only for the hours of the appointment (see „Set up a person's access by location“ (documentation of the administration app)). Through the API, you can also issue a key that's restricted to one database and expires at the end of the day:

   POST /admin/v1/issue-key
   Content-Type: application/json
    
   { "person": "Vertrieb Präsentation", "label": "Power BI beim Kunden", "readOnly": true,
     "totpExempt": true, "databases": [ "fachdaten" ], "expiresAt": "2026-10-08T18:00:00Z",
     "delivery": "link" }

5. Optionally, limit data access to countries, for example „Germany only“. This requires a loaded geolocation database (see Check sign-in patterns and origins). Exclude the corporate network by its addresses, because a request from there has no country, and create the rule and its exceptions in one step:

   POST /admin/v1/save-sign-in-rule
   Content-Type: application/json
    
   { "scope": "Data", "effect": "Deny", "label": "Germany only",
     "exceptCountries": [ "DE" ], "exceptFrom": [ "10.0.0.0/8" ],
     "exceptions": [ { "persons": [ "John Doe" ], "countries": [ "TH" ],
                       "until": "2026-11-02T00:00:00Z", "label": "vacation" } ] }

   The exception also admits John Doe from Thailand until November 2 and ends on its own. To see what applies to him in Thailand, call explain-sign-in with the origin { "name": "Thailand", "address": null, "country": "TH" }; details under Exceptions with an end.

6. Check from outside (mobile network or a network outside the exception): data access with a personal key requires a code, but not in the office. In the administration app, Anmeldung und Rechte (Sign-in and rights) of a person shows the same for every origin, without the person having to sign in.

To revert. If a rule locks out people it shouldn't, turn the rule off in the administration application. If administration is affected too, the remove-sign-in-rule command removes the rule on the server (see Commands on the server).

• An unknown origin is within the scope of every rule—a request whose origin the service can't determine therefore doesn't count as „inside“.
• A country is only a hint. A VPN, a proxy or a mobile network moves the origin to another country. A rule by country adds to keys, networks and the second factor; it doesn't replace them. A country that can't be determined doesn't count as „Germany“.
• After the presentation, block the report key or let it expire.
• On the train, signing in to the administration app takes longer, mainly because it links its sets during sign-in. The driver retries dropped connections itself.

• „Set up a person's access by location“ (documentation of the administration app)—the same in the administration app, in eight steps
• HTTP: sign-in policy and second factor