io.undertow.security.api.AuthenticationMode Maven / Gradle / Ivy
Go to download
This artifact provides a single jar that contains all classes required to use remote EJB and JMS, including
all dependencies. It is intended for use by those not using maven, maven users should just import the EJB and
JMS BOM's instead (shaded JAR's cause lots of problems with maven, as it is very easy to inadvertently end up
with different versions on classes on the class path).
The newest version!
/*
* JBoss, Home of Professional Open Source.
* Copyright 2014 Red Hat, Inc., and individual contributors
* as indicated by the @author tags.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package io.undertow.security.api;
/**
* Enumeration to indicate the authentication mode in use.
*
* @author Darran Lofthouse
*/
public enum AuthenticationMode {
/**
* Where the authentication mode is set to pro-active each request on arrival will be passed to the defined authentication
* mechanisms to eagerly perform authentication if there is sufficient information available in order to do so.
*
* A pro-active authentication could be possible for a number of reasons such as already having a SSL connection
* established, an identity being cached against the current session or even a browser sending in authentication headers.
*
* Running in pro-active mode the sending of the challenge to the client is still driven by the constraints defined so this
* is not the same as mandating security for all paths. For some mechanisms such as Digest this is a recommended mode as
* without it there is a risk that clients are sending in headers with unique nonce counts that go unverified risking that a
* malicious client could make use of them. This is also useful for applications that wish to make use of the current
* authenticated user if one exists without mandating that authentication occurs.
*/
PRO_ACTIVE,
/**
* When running in constraint driven mode the authentication mechanisms are only executed where the constraint that mandates
* authentication is triggered, for all other requests no authentication occurs unless requested by the internal APIs which
* may be exposed using the Servlet APIs.
*/
CONSTRAINT_DRIVEN;
}