Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
G
go-sso
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
id
go-sso
Commits
fe763606
Commit
fe763606
authored
5 years ago
by
ale
Browse files
Options
Downloads
Patches
Plain Diff
Add sso-proxy documentation to the README
parent
347348a9
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
README.md
+51
-0
51 additions, 0 deletions
README.md
with
51 additions
and
0 deletions
README.md
+
51
−
0
View file @
fe763606
...
...
@@ -102,6 +102,57 @@ associated key will be cleared either on logout, or when the login
session expires.
# SSO Proxy
The
*sso-proxy*
server adds SSO authentication and access controls to
unauthenticated backends (legacy applications, or apps that do not
support authentication altogether).
It is a straightforward reverse proxy that handles the SSO-related
methods directly and forwards everything else unchanged to the
backend. While it is possible to specify multiple backends for each
endpoint, the load balancing algorithm is extremely unsophisticated:
the proxy will simply pick a random backend on every request, without
any tracking of whether backends are up or not (this is obviously
improvable). Also note that the authenticated identity is
**not**
passed along to the backend: since the backends are unauthenticated,
it wouldn't be safe for them to trust this information anyway, unless
they have a way to ensure it comes only from the trusted sso-proxy
(perhaps using TLS or other forms of transport verification). Finally,
*sso-proxy*
only handles incoming requests based on their Host
attribute, not the request path.
The proxy server has its own configuration file,
*/etc/sso/proxy.yml*
by default, which has the following attributes:
*
`session_auth_key`
and
`session_enc_key`
are secrets to be used for
HTTP-based sessions. For details on their syntax see the description
for
`session_secrets`
above.
*
`sso_server_url`
is the URL for the login server
*
`sso_public_key_file`
should point at a file containing the SSO
public key
*
`sso_domain`
is the SSO domain
*
`backends`
is the list of configured endpoints and associated
backends, each entry has the following attributes:
*
`host`
the HTTP host to serve
*
`upstream`
is a list of
*host:port*
addresses for the upstream
backends
*
`tls_server_name`
allows you to explicitly set the value of the
ServerName TLS extension on the outbound request. This is done do
de-couple the transport layer between proxy and backend from the
details of the actual HTTP request.
*
`client_tls`
specifies the client TLS configuration. If set, the
upstream request will use HTTPS, otherwise plain HTTP. Known
attributes:
*
`cert`
: path to the client certificate
*
`key`
: path to the private key
*
`ca`
: path to the CA used to validate the server
Given its characteristics, the proxy is currently best suited for
relatively low-volume, administrative applications, rather than for
user-visible services.
# API
The
*sso-server*
binary serves different types of HTTP traffic:
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment