Package com.codename1.backend.security
package com.codename1.backend.security
Authentication and authorization for the routes of a backend, in the shape
of Spring Security: an application declares one or more
SecurityFilterChain beans, each built from
the HttpSecurity its method is handed, and
every request the server does not answer on its own behalf is put to them.
A server with no such bean links none of this.
-
ClassDescriptionThe parts every
Authenticationshares: its authorities, its details and the name read off its principal.The caller may not do what it asked.Answers a signed-in caller that asked for something it may not have.Answers 403.The account has expired.The account exists and may not be used as it stands: locked, disabled or expired.Gives a request nobody signed in for anAnonymousAuthenticationToken, so the rules that follow always have an authentication to judge.Who a request is from when nobody signed in: a principal calledanonymousUserholdingROLE_ANONYMOUS, so authorization rules always have someone to ask about.The authentication of a request nobody signed in for; seeAnonymousAuthenticationToken.Matches a request's path against an Ant-style pattern, and optionally its method.Matches every request.Authenticates a request from the API key it presents, inX-API-Keyor asAuthorization: Bearer <key>.Sign-in with an API key on each request.Grants access by whether the caller signed in at all.Who a request is from: a credential presented for checking, or -- once anAuthenticationManagerhas accepted it -- the principal and what it may do.Keeps one kind ofAuthenticationin the HTTP session, and makes it again on the next request.Answers a request that has to authenticate first: with a challenge, or a redirect to where the user signs in.The request could not be authenticated.Answers a sign-in that was refused.Decides whether a presentedAuthenticationis genuine.Chooses what authenticates a request, by the request: a server with several tenants, or tokens from several issuers.One way of checking anAuthentication: aProviderManagerasks each of its providers that supports the token's class.Authentication could not be attempted at all: the user store failed, or the layer is misconfigured.Answers the request that signed a user in.A decision that turned on what the caller is granted, with the authorities any one of which would have done.Grants access to an authenticated caller holding one of a set of authorities.Granted, or not.Puts the request to the chain's authorization rules, and throwsAccessDeniedExceptionwhen they refuse it.Decides whether an authentication may reach something: for a request rule, aRequestAuthorizationContext.Makes the server an OAuth2 authorization server and OpenID Connect provider.The authorization rules of a chain: which requests need what.The credentials are wrong: an unknown user or a password that does not match.Answers 401 with the challenge that makes a client send HTTP Basic credentials:WWW-Authenticate: Basic realm="Realm".Authenticates a request from itsAuthorization: Basicheader.Authenticates a request from its bearer token.Where the parts of the layer that judge time -- a token's expiry, a rate limit's window -- read it from, so a test can move it.Keeps the token in a cookie,XSRF-TOKEN, for a page whose script reads the cookie and sends its value back in theX-XSRF-TOKENheader -- the convention Angular and axios follow.The password was right and has expired.Protection against cross-site request forgery.A state-changing request did not prove it came from the application's own pages.Refuses a state-changing request that does not carry the chain's CSRF token.The token a page sends back with a state-changing request to show the request came from the application's own pages.Where a chain keeps the CSRF token it expects a client to send back.Customizer<T>Configures one part of anHttpSecurity: the lambda handed toformLogin,csrf,authorizeHttpRequestsand the rest.Checks a username and password against aUserDetailsService: loads the user, compares the password through aPasswordEncoder, and refuses an account that is locked, disabled or expired.ACsrfTokenthat is its three values.Serves a plain login page atGET /loginfor a chain that uses form login and names no page of its own.ASecurityFilterChainthat is a matcher and a list of filters: whatHttpSecurity.build()returns.The account is disabled.How a chain answers a request that must sign in, and one that may not have what it asked for.Turns the security exceptions thrown by what follows it -- the authorization rules, a controller, a service the controller calls -- into answers.The rest of the chain, as aSecurityFiltersees it: the filters after it and then the application's routes.Sign-in through an HTML form.One thing anAuthenticationhas been granted: a role, writtenROLE_ADMIN, or any other authority the application checks by name.The security headers a chain puts on its responses.Content-Security-Policy.X-Frame-Options.Strict-Transport-Security.A header that is either sent or not.Writes a header onto every response a chain's requests get:The headers of the response being written.Holds the chain'sHeaderWriters.Answers 403: what a chain with no way of signing in says to a request that would have to.Sign-in with HTTP Basic credentials on each request.Builds oneSecurityFilterChain.Keeps the token in the HTTP session: the default.Remembers the address in the HTTP session, underHttpSessionRequestCache.SAVED_REQUEST.Keeps who is signed in in the HTTP session, underHttpSessionSecurityContextRepository.SPRING_SECURITY_CONTEXT_KEY.Answers with a status and nothing else:new HttpStatusEntryPoint(401)for an API whose clients know how to authenticate without being told.After sign-out, answers with a status and no page: for an API.The request is anonymous, or not authenticated strongly enough, for what it asked for.The request's CSRF token is not the one the server issued.The account is locked.Sends a request that has to sign in to the login page, with a 302.Sign-out:POST /logoutends the session, forgets who was signed in and redirects to/login?logout.Signs the user out when a request asks for it --POST /logoutunless configured otherwise -- and answers with the chain'sLogoutSuccessHandler.Something to undo when a user signs out: a session, a cookie, a stored token.Answers the request that signed a user out.A second factor at sign-in.The request carried a CSRF token and the server holds none to compare it with -- the session it belonged to is gone -- or carried none at all.Remembers nothing.Keeps nothing: every request authenticates itself.Answers the endpoints of an authorization server a user must be signed in for: the authorization endpoint and the device verification page.Starts a sign-in at an identity provider: keeps the request this browser is sent away with, and redirects it to the provider.Answers the endpoints of an authorization server that a client calls as itself: the token, revocation, device authorization, JWK Set, user info and metadata endpoints.Ends a sign-in at an identity provider: takes the provider's answer at/login/oauth2/code/{registrationId}, holds it to the request this browser was sent away with, exchanges the code, verifies the ID token and signs the user in.Sign-in through another identity provider, with OAuth2 or OpenID Connect.Sign-in with a bearer token on each request: the routes under the chain are an OAuth 2.0 resource server, and the token is a JWT.How the JWTs of a resource server are verified and read.AnAuthenticationManagerthat asks a list ofAuthenticationProviders in order and takes the first answer.NoAuthenticationProviderof aProviderManagerchecks tokens of the class it was handed.The rate limits of a chain; filled in byHttpSecurity.rateLimit(RequestMatcher, RateLimitKeyResolver, RateLimiter).Answers 429 to a request that is over one of the chain's rate limits; seeHttpSecurity.rateLimit(RequestMatcher, RateLimitKeyResolver, RateLimiter).Recognizes a returning user by their remember-me cookie, on a request nobody has signed in for.Who a request is from when the user was recognized by a remember-me cookie rather than signing in during this session.Remember-me: a cookie that signs a returning user in.What a request rule is asked about: the request, and the variables its pattern bound.Remembers where an anonymous request was going, so that signing in can send the user there instead of to a fixed page.Whether a chain remembers where an anonymous request was going; seeRequestCache.Decides whether a rule applies to a request: which chain guards it, which authorization rule covers it, which requests CSRF protection leaves alone.Whether a request matched, and the variables its pattern bound.Combines matchers: all of them, any of them, or not one.After sign-in, sends the user to the page that asked them to sign in, or to a default when they came to the login page on their own.Asks a user who has a second factor for it, between their password being accepted and their being signed in.Stands between a user passing their first factor and being signed in.One configurable part of anHttpSecurity: form login, CSRF protection, the authorization rules.What the security layer knows about the thread's current request: who it is from.Where a chain keeps who is signed in between requests.Who the calling thread's request is from.Loads who is signed in from the chain'sSecurityContextRepositoryintoSecurityContextHolderbefore anything else looks.ASecurityContextthat holds its authentication and nothing else.Where a chain keeps who is signed in between one request and the next.What a chain keeps about the request the calling thread is serving, beyond the request itself: attributes filters hand one another, and headers for the response that is yet to come back.One step of aSecurityFilterChain.The filters that guard some of a server's requests.The tables the security layer's database-backed stores keep, as a migration set of the layer's own.The server is doing as much of something expensive as it was told it may, and this request would have been one more: it is turned away at once, rather than queued behind work that is already late.Whether a chain may use the HTTP session.Whether a chain uses the HTTP session, and what happens to it at sign-in.How a chain signs a user in to a session, once some mechanism has established who they are.An authority that is its name and nothing else.After a refused sign-in, sends the user to a page -- the login page with?error, usually -- or, with no page set, answers 401.After sign-out, sends the user to a page.Signs a user in from the login form: a POST to the login processing URL carryingusernameandpassword.A username and password: as a client presented them, or -- with authorities -- as anAuthenticationProvideraccepted them.Signs a user in with a passkey: hands out the options of a sign-in atPOST /webauthn/authenticate/options, and takes the authenticator's answer atPOST /login/webauthn.Passkeys: a user who is signed in registers one, and from then on signs in with it.Lets a signed-in user register a passkey, and remove one of theirs: