Multicraft SSO
You set up multicraft sso by linking the PHP panel to your identity system. This setup lets your team log in with one main account instead of local passwords. Most teams use custom login scripts or web server rules to check user tokens. Still, giving a user a broad panel role still leaves your hosts and databases exposed. How multicraft sso works in your setup The control panel runs as a PHP web app that talks to a backend daemon. By default, the panel stores user names and password hashes in
Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up multicraft sso by linking the PHP panel to your identity system. This setup lets your team log in with one main account instead of local passwords. Most teams use custom login scripts or web server rules to check user tokens. Still, giving a user a broad panel role still leaves your hosts and databases exposed.
How multicraft sso works in your setup
The control panel runs as a PHP web app that talks to a backend daemon. By default, the panel stores user names and password hashes in a local SQL database. To use single sign-on, you replace or wrap this local login step. Your web server checks the user with your identity provider before loading the panel.
Once the identity provider confirms the user, it sends a token back to the app. A custom script or login module reads the email or group from that token. It then matches that user to an existing account inside the panel database. If the user is new, the script can create a profile and assign a role.
The panel uses roles to decide what a user can see and do. You can set up roles for guests, moderators, server owners, or full superusers. The web app checks these roles when a user clicks a button in the browser. Then the panel sends the command over a socket to the backend daemon.
What single sign-on solves and what it misses
Linking the panel to your identity provider fixes password sprawl across your team. You do not need to share local admin passwords in chat apps or spreadsheets. When someone leaves the team, you turn off their main account in one place. You can also require multi-factor checks before anyone reaches the web login screen.
Still, single sign-on only checks who can log in at the start of a session. It does not check what commands or queries a user runs after they log in. A user with a broad admin role can still change daemon settings or delete files. They can also open the built-in console and run destructive commands on the game server.
Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The risk grows when engineers need to fix the panel database or the Linux host. Panel login rules do not cover direct SSH sessions or MySQL database queries. Engineers often share root SSH keys or database passwords to fix broken nodes. Those raw SQL queries can return user emails, phone numbers, or card numbers in plain text.
Securing backend hosts and databases
Running a game server fleet requires more than just a web panel login. Your team must manage the Linux hosts, the daemon processes, and the SQL backends. When a node fails, engineers bypass the web app and connect to the host directly. Relying only on web panel roles leaves this entire backend layer without fine-grained controls.
To secure the full stack, you must control every command and query in flight. You need a way to link every SSH session and SQL query to a real person. You also need rules that rewrite sensitive fields like emails or phone numbers in query results. Adding approval steps before someone runs a host command keeps one mistake from taking down servers.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does the panel support SAML or OIDC out of the box?
No, the standard panel uses its own internal database to check user logins. You must add a web server module or write custom PHP login code to use SAML or OIDC.
How do identity provider groups map to panel roles?
Your custom login script reads the group claims sent by your identity provider. The script then updates the user role inside the panel database through the built-in API.
Does web single sign-on secure the built-in FTP server or MySQL database?
No, web single sign-on only covers the browser login flow for the PHP panel. FTP file transfers, SSH host sessions, and direct SQL queries still need their own access controls.