Most people treat authentication as an application problem. If an internal dashboard, an admin panel, or a legacy tool doesn't have a login screen, the reflex is to open the codebase and start wiring up an auth library — OAuth clients, session management, user tables, password resets, the whole thing.
That's a lot of work to do once, and it's even worse when you have ten different apps that all need it.
There's a faster way: put the authentication layer in front of your apps instead of inside them. A self-hosted WAF that sits as a reverse proxy in front of your services can handle login for you — before a single request ever reaches your application code.
Here's how SafeLine does it, and how you can add both password protection and full SSO to any web app without touching its source.
Why do auth at the WAF layer?
A WAF is a reverse proxy: clients connect to the WAF first, the WAF filters and forwards traffic to your origin server. Because every request already flows through it, the WAF is a natural place to gate access.
That means:
- No code changes. The app behind the WAF doesn't need an auth library, a user table, or any login UI of its own.
- One place to manage. Instead of maintaining credentials in ten apps, you manage them in one console.
- It works for anything. Legacy apps, static sites, internal tools, APIs — anything the WAF fronts can be protected.
SafeLine provides two authentication modes to cover different situations: Simple Auth and SSO.
Simple Auth vs SSO: two ways to gate access
SafeLine gives you two distinct modes, and the difference comes down to scope:
- Simple Auth is application-specific. A user logs in to access that one application. If they move to a different app, they authenticate again.
- SSO (Single Sign-On) is the opposite. A user logs in once and then accesses multiple related applications without repeated logins.
Think of Simple Auth as "lock this one door," and SSO as "issue one badge that opens every door you're allowed into."
Simple Auth: password-protect a single app
With Simple Auth turned on for an application, visitors must enter valid credentials before they can reach the app. Anyone who doesn't hold the credentials is blocked.
When you configure Simple Auth for an application, you pick a login method and set an Auth Callback URL.
The login method is how users prove who they are. SafeLine supports four:
- Account + Password — a basic username/password login.
- GitHub — sign in with a GitHub account.
- OIDC — sign in through an OpenID Connect identity provider.
- LDAP — sign in with an existing enterprise directory account.
The Auth Callback URL is what lets you pass the authenticated user's identity into your app, which I'll cover in detail below.
SSO: one login, every app
SSO is where this gets genuinely useful for teams. Once unified authentication is enabled, your users get a single sign-in entry point — an SSO center — and from there they can reach every application that has joined.
The docs describe three business scenarios where this fits naturally:
- Enterprise application portal. Internal systems like OA, HR, and CRM each have their own auth today. With SSO, employees log in once and reach all of them, while IT centralizes access policy.
- Modernizing legacy apps. Older apps often have no built-in auth, or a dated mechanism. SSO adds a modern authentication layer on top without modifying application code.
- Zero trust. SSO is a core piece of a zero-trust architecture, giving every application access a consistent identity-verification and authorization path.
Enabling SSO
You enable SSO from the Auth-Settings page under the SSO tab. The configuration is a handful of fields:
| Field | What it's for |
|---|
| Domain | The domain users visit to reach the unified authentication center (e.g. home.in.example.cn) |
| Port | An available port for the center |
| SSL | Optional, for HTTPS |
| Login Methods | The identity methods available (multiple can be enabled) |
| Force Enable TOTP | When on, every SSO user must use TOTP for two-factor authentication |
Once enabled, users in the user list can access the SSO center by default.
Adding apps to SSO
To bring an application into SSO, go to Applications, click the app's AUTH button, and switch it over. Then you configure two fields:
- Application Redirect URL — where the user is sent when they click the app in the SSO center.
- Auth Callback URL — how authentication info is passed to the app server.
After that, when a user visits an application for the first time, they authenticate once. From then on, that one authentication covers every authorized application that has joined SSO.
A few details worth knowing from the SSO docs:
- There is no limit on how many applications can join SSO.
- You can edit an application's name and logo in the SSO center.
- Users can only access applications they have permission for — joining SSO doesn't grant access to everything by default.
- Logging out of the SSO center is not SLO (single logout) — that's not currently supported.
The four login methods
Whichever mode you use, the actual identity check is done by one of four methods.
Account + Password
The simplest option. You configure a username and password, and visitors enter it to get through. It's a good fit for a single admin or a small set of trusted users.
GitHub
SafeLine can let users sign in with their GitHub identity. You create a GitHub OAuth application to get a ClientID and ClientSecret, then fill those into SafeLine's third-party login configuration. The callback URL for GitHub follows the pattern:
https://your-app.com/.safeline/auth/api/callback/github
There's also an "Auto Merge Account" option to match incoming GitHub logins to existing accounts by email.
OIDC
For organizations that already run an identity provider, SafeLine speaks OpenID Connect. The docs call out Keycloak, Auth0, Okta, and Azure AD as supported providers.
Configuring it means pointing SafeLine at your provider's discovery URL (for Keycloak, something like https://{keycloak-host}/realms/{realm-name}) plus a Client ID and Client Secret. This is the method to reach for when you want your apps to trust the identity system you already have.
LDAP
For enterprise directories, SafeLine supports LDAP — including Microsoft Active Directory, OpenLDAP, and Apache Directory. Users log in with their existing enterprise accounts.
Configuration is the standard set of LDAP fields: a server URL (ldap://host:389 or ldaps://host:636 for SSL), a Bind DN, a Bind password, a user base DN, and a query condition. The query condition uses %s as a placeholder for the username, for example:
(&(objectClass=person)(uid=%s))
This is the one to use when you want a self-hosted gateway in front of an on-premise directory.
Passing the authenticated user into your app
Blocking unauthenticated traffic is only half the story. Often your app needs to know who just logged in. SafeLine handles this with a callback flow.
After a user authenticates, SafeLine redirects to your configured Auth Callback URL, appending a short-lived code:
http://example.com/application?code=123456&redirect_uri=original_user_access_address
Your application then exchanges that code for the user's identity by calling SafeLine's user-info endpoint:
GET http://safeline-console.com/.safeline/auth/api/user?code=123456
X-SLCE-API-TOKEN: safeline-api-token
The response gives you the user's id and username. Two things to note: the code can only be used once, and you'll find the API token in the console under Settings → Management.
After your app obtains the user info, it should cache the login state to decide whether the user is logged in for subsequent requests, then redirect to the redirect_uri. If retrieving the user info fails, your app should delete cookies with the sl_auth_session_ prefix and prompt the user to authenticate again.
Approvals and conditional auth
Two more knobs round out the picture, both under the app's AUTH advanced configuration:
- Approval configuration. You can require that first-time users trigger an approval request after authenticating, which an admin must approve before the user gets in. Or you can let users access directly after authentication. The former is handy for sensitive internal tools where you want a human in the loop.
- Conditional authentication. You can enable authentication (or skip it) only when specific conditions are met — for example, requiring auth for certain paths while letting other traffic pass.
Wrapping up
Authentication doesn't have to be a per-app engineering project. Because a self-hosted WAF already sits in front of your traffic, it's the natural place to gate access — and SafeLine turns that into a real feature set: per-app password protection, unified SSO across your apps, and four identity methods (password, GitHub, OIDC, LDAP) to choose from.
The result is that an internal dashboard, a legacy tool, or a static site can all get a proper login screen — and SSO — without a single line of application code changing.
If you want to try it yourself, the setup starts with a single command. The full authentication documentation is at docs.waf.chaitin.com.
FAQ
Does adding auth at the WAF layer slow down my app?
The check happens at the reverse-proxy layer before traffic reaches your origin, so your application itself isn't doing any extra work. The main cost is the one-time configuration.
Can I use SSO for both internal and public apps?
Yes. The mode is per-application, so you can put internal tools behind SSO while using Simple Auth or no auth on public apps, all from the same console.
Which identity provider should I pick?
If you already run Keycloak, Auth0, Okta, or Azure AD, OIDC is the natural fit. If you have an enterprise directory, use LDAP. GitHub is convenient for developer-facing tools, and Account + Password is fine for a small number of trusted users.
Do I have to modify my app to know who logged in?
Only if your app needs the user's identity. In that case you implement the callback flow (exchange the code for user info). If you just need to gate access, no code changes are required at all.
Does SafeLine's SSO support single logout?
Not currently. Logging out of the SSO center is not SLO.
Which of the four login methods — password, GitHub, OIDC, or LDAP — fits your current stack?
Ready to protect your sites without paying for a cloud WAF?