Controlling Who Gets In
Enabling a sign-in source lets people authenticate. What they can then reach is a separate decision, and this is where it is made.
Where to find it
Architect Panel → Security:
- Permissions — what a new external identity lands in
- Disabled User Accounts — closing an account
- User Verification — proving something before granting more
Architect Panel → Configuration:
- Site Settings — Force External Users to Login
Authentication is not authorisation
The principle behind everything here. Somebody signing in with Google has proved they control a Google account. That is all — it says nothing about whether they should see anything of yours.
Enabling a social login without deciding what a new identity gets is how an open sign-in route becomes an open door.
Default groups do the work
What an externally-authenticated user lands in decides what they can reach. Keep it minimal — their own profile and public content — and require something further for anything else.
Check it by signing in through that route yourself and looking, rather than reasoning from configuration.
Verification as the upgrade
The clean pattern for external populations: let anybody authenticate, and require verification to gain a group. That keeps sign-in frictionless while making access something earned and reviewable.
Approval where the population should be closed
Where external users should be a known set rather than anybody who arrives, an approval step is the control — an account exists and reaches nothing until somebody confirms it should.
If you do that, make sure the queue is somebody's job. An approval queue nobody works is a set of people who cannot use your service and do not know why.
Force External Users to Login
A separate setting worth understanding precisely, because its name suggests something broader than it does. It redirects visitors arriving from IP addresses outside your whitelisted ranges to the sign-in page.
So it is a network-based control — "people outside our offices must sign in" — rather than a general rule about external users. Useful for an application that should be open inside the building and closed outside it, and it depends entirely on your IP ranges being correct and current.
Review external accounts periodically
They accumulate more quietly than staff accounts, because nobody owns the leaver process for them. Look for accounts unused for a long time, and for anybody whose access no longer matches why it was granted.
Closing off a route
Disabling a sign-in method stops new authentication through it. Consider what happens to people who used it — whether they have another way in, and whether they should.
Worked example
A partner portal allows Google and Microsoft sign-in. A new identity lands in a group granting nothing but its own profile. Verifying an employer e-mail domain awards the partner group. Accounts unused for eighteen months are disabled after a warning, and the whole arrangement was tested by signing in as a genuinely new external user before launch.
Recommendations
- Decide what an external identity gets before enabling the route.
- Verify to upgrade rather than approving everybody by hand.
- Staff any approval queue you create.
- Review external accounts — nobody else will.