Identity provider and SSO for Kupolo.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Adrian Malacoda 0f3770157d use correct title for error page too 1 month ago
integration-tests add readme 1 year ago
lua add an example lua module for user store 11 months ago
res use correct title for error page too 1 month ago
src use correct title for error page too 1 month ago
.gitignore add gitignore 9 months ago
Cargo.lock Rename who_server -> kupolo 1 month ago
Cargo.toml Rename who_server -> kupolo 1 month ago
LICENSE Add LICENSE. 8 months ago
README.md Add LICENSE. 8 months ago
ROADMAP.md add config parsing to roadmap (phase I) 1 year ago
build.rs remove javascript file, who server will try to avoid javascript as long as possible 5 months ago
package.json Remove browserify since we don't have any javascript (yet) 1 month ago
rust-toolchain add rust-toolchain file for nightly 1 year ago
who-server-2.toml add an example lua module for user store 11 months ago
who-server.toml make url key in config optional, since it can be determined from request 9 months ago

README.md

Who server

This is the Who identification/authentication service and identity provider. It implements the Project Badger authentication protocol (OpenID Connect with Discovery and Self-Registration) and provides a means to authenticate local and remote users, which can be used in any number of applications. Who server will be deployed to the flagship Project Badger server at monarch-pass.net, and can optionally be used by other servers participating in Project Badger.

Identification

The Who server uses the Who library to identify users by an identifier such as a http[s]:// or acct: URI. The Who server can return zero or more user accounts associated with that identifier.

Authentication

Users identified by the Who server may broadly grouped into internal or external users. When the user enters their identifier into the Who server, if there are multiple accounts discovered, they may be prompted to choose one to authenticate with. If there is only one, the Who server may automatically proceed with the flow for that account (e.g. OAuth redirect, password prompt).

Internal or Local users

Who server can be connected to a local user account store (e.g. LDAP, or a table in a database) and provide a password login, with optional two-factor auth support.

If the Who server is connected to a local user account store, registration can be enabled. Who can send events to interested applications when a user is registered.

External or Remote users

Who server can authenticate users of external servers, such as OpenID, OpenID Connect, certain proprietary OAuth services, and even other Who servers. Note that, strictly speaking, the Who server only wants to authenticate such users; it does not need to be authorized to access the user’s data on that external service. Therefore, the Who server should only be granted only the scopes necessary to authenticate users.

Integration

An application using the Who server for authentication can integrate using protocols such as OAuth 2/OpenID Connect, CAS, SAML, IndieAuth, or some other protocol. Such applications might not necessarily be hosted on the same server as the Who service.

License

GNU Affero GPL v3