VPN SSO and SAML

OpenConnect profiles can authenticate through your identity provider instead of a stored password. Okta, Azure AD, and Duo all work, MFA included. Pro tier and above.

The two-phase flow

The problem with SSO in a VPN client is that the identity provider wants a real browser — cookies, device trust, WebAuthn, push prompts — but the tunnel wants root. ShellYard splits those.

1. Browser phase, unprivileged. ShellYard opens the IdP login in your actual default browser. Your existing session, your password manager, your hardware key, your Duo push. Complete the login exactly as you would for any other corporate app.
2. Tunnel phase, privileged. The browser hands back an auth cookie. ShellYard passes that cookie to the VPN client on stdin and prompts for admin rights only to bring the interface up.

Your IdP credentials never pass through ShellYard. It receives the resulting cookie, not your password, and never your second factor.

Setting it up

In the profile editor, set the auth method to Browser SSO. Leave the credential field empty — SSO profiles don’t use one.

If the gateway offers several tunnel groups, use auth-group discovery to query it and pick the SSO-enabled group from the returned list. Picking the wrong group is the usual cause of “it keeps asking for a password instead of opening the browser” — many gateways expose both a password group and an SSO group on the same hostname.

If the browser never opens

The most common cause is a gateway that only advertises browser auth to clients it recognizes as AnyConnect. ShellYard sends a real AnyConnect user agent for exactly this reason, but some gateways are configured to gate SSO by client certificate or by auth group as well.

Check, in order:

1. The auth group is the SSO one (re-run discovery)
2. The profile’s auth method is Browser SSO, not password
3. The per-profile log in ~/.shellyard/vpn/ — the gateway’s advertised auth methods are recorded there at connect time

Shared SSO profiles

An SSO profile is the cleanest thing to publish in a Shared Space: there’s no credential to share, because every member authenticates as themselves. Admin creates the profile once, every member connects with their own identity, and your IdP logs show real per-user attribution instead of a shared service account.