At runtime, the following security sequence is performed for ADF Security protected applications:
1. A user requests an ADF bound ADF Faces page or bounded task flow.
2. The ADF Security layer in ADF checks whether security is enabled for the ADF
application configuration.
3. If security is enabled, the security layer checks whether security is enabled for
authentication only or for authorization, too.
4. If authorization is enforced, ADF Security checks whether an anonymous principal exists and if the permissions granted to anonymous users are sufficient to run the page or task flow. This usually is the case for public pages. However, it is important to note that page and task flow permissions must be explicitly granted to the anonymous role to make them publicly accessible.
5. If page access is not possible with the privileges of the anonymous user account, the framework triggers authentication by redirecting the request to the protected ADF authentication servlet.
6. The servlet delegates the authentication request to the Java EE container.
7. Using Oracle WebLogic Server, the container responds to the request with a login form or by sending a response header that makes the browser display its login form.
8. The user-provided credentials are checked against the identity stores that are configured for the WebLogic Server domain. If authentication is successful, the server redirects the request to the authentication servlet. The session now is authenticated and the user Subject contains the user and enterprise group principals.
9. If ADF Security is configured to use a single application entry point for authenticated users, the authentication servlet directs the request to this page. If not, it directs the user to the originally requested page.
10. ADF Security now checks whether the user Subject has permission to run the requested resource. For this, it performs permission checks for the page or task flow in the context of the authenticated user.
Thanks to Frank Nimphius for the valuable info.