Abstraction for some access data, e.g.
Abstraction for some access data, e.g. service token, grant, role, scope
This filter acquires the access and then forwards the request to upstream service
This filter acquires the access and then forwards the request to upstream service
It binds to the upstream service endpoint using the info passed in ServiceIdentifier
Describes a service that acts as an Access issuing endpoint, this would be something like an OAuth2 token service, or an LDAP server, or a database that holds access tokens for user credentials
The identification information needed by the AccessIssuer to issue access data for your request
The identification information needed by the AccessIssuer to issue access data for your request
This can be thought of as a function (A, ServiceIdentifier) => Req
This response contains the access data needed by an authenticated endpoint, e.g.
This response contains the access data needed by an authenticated endpoint, e.g. grants, tokens, api keys
This exception stores the response code
Certificate processing error
This exception stores the response code
Token Parsing error
Certificate processing error
Determines the service that the request is trying to contact If the service doesn't exist, it returns a 404 Not Found response
PODs
Top level filter that maps exceptions into appropriate status codes
A request to gain an Identity
, e.g.
A request to gain an Identity
, e.g. email/password credentials
Note: this wouldn't be used for most cases of something providing external authentication, like in the case of SAML, since the user would have been redirected to an external IdP for logging in.
A response from the identity provider with some identity
A response from the identity provider with some identity
Example: SAML POST response to a successful login to a third party IdP
This encapsulates the notion of an identifier that the AccessIssuer can understand.
This encapsulates the notion of an identifier that the AccessIssuer can understand. In the case of OAuth2 we would wrap a the Access Token grant, or for SAML we would wrap the SAML token, then we hand this off to the AccessIssuer
Determines the identity of the requester, if no identity it responds with a redirect to the login page for that service
Abstraction for those that are directing requests directly to the Identity Provider
Logout Service - Deletes the session - sets the empty cookie in response - redirects to default service path
This filter rewrites Request Path as per the ServiceIdentifier configuration
Send the request on AccessIssuer chain
Send the request on AccessIssuer chain
This filter only deals with Authneticated SessionIds or forwards it to next filter
Send the request on IdentityProvider chain
Send the request to Unprotected Service
Send the request to Unprotected Service
This filter only deals with the Request has SessionId (Authenticate or Untagged) and destined to unprotected Service. Everything else is forwarded to the next filter in the chain.
Ensures we have a SignedId present in this request, sending a Redirect to the service login page if it doesn't
This provides the specification contracts for doing auth in the form of Type Classes in auth.Access and auth.Identity
Taking SAML 2.0 and OAuth2 as example flows, we have defined a set of contracts and abstractions on those contracts to allow users of this library to implement instances of their specific authentication/authorization.
The flow for a typical SAML/OAuth2 involves a protected resource, a client (web browser), and an Identity Provider. Border Patrol can act as a translation layer for external representation of access and internal representation so that services behind it do not need to implement SAML/OAuth2.
The primary abstractions are:
Identity
the external identity provider and types, e.g. SAML IdPAccess
the internal access provider and types, e.g. api tokens, jwt etc