kupolo
/
kulogin
1
0
Fork 0
Code Issues 16 Pull Requests Releases Wiki Activity
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.
168 Commits
1 Branch
0 Tags
845 KiB
 
 
 
 
Branch: master
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from 'master'
${ noResults }
 ZIP  TAR.GZ
Adrian Malacoda 0f3770157d
use correct title for error page too 		2 years ago
integration-tests add readme 3 years ago
lua add an example lua module for user store 2 years ago
res use correct title for error page too 2 years ago
src use correct title for error page too 2 years ago
.gitignore add gitignore 2 years ago
Cargo.lock Rename who_server -> kupolo 2 years ago
Cargo.toml Rename who_server -> kupolo 2 years ago
LICENSE Add LICENSE. 2 years ago
README.md Add LICENSE. 2 years ago
ROADMAP.md add config parsing to roadmap (phase I) 3 years ago
build.rs remove javascript file, who server will try to avoid javascript as long as possible 2 years ago
package.json Remove browserify since we don't have any javascript (yet) 2 years ago
rust-toolchain add rust-toolchain file for nightly 3 years ago
who-server-2.toml add an example lua module for user store 2 years ago
who-server.toml make url key in config optional, since it can be determined from request 2 years 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