Realize that the main purpose of CADI in the authentication sphere is to identify first which Authentication scheme is being used. Therefore, when you’re debugging, you’ll find the terms “TAF” and “EpiTaf”. The first, just think of it as a pluggable Authentication Module, only one of which is Basic Auth. The others, in AT&T typically include “CSP Global Logon” and “X509 Certificates”.
TAF - “Transmutative Authentication Framework”, these are essentially plugable Authentication elements. Each is able The “EpiTaf” is a pun, of course, but it’s software purpose is to run each Module against the incoming transaction. Each of which is a different scheme, and looks for different things.
Reading the Security Info¶
X509 – This checks the core HTTP stream to get a Client Certificate IF it is provided. If so, it validates that it is signed by a trusted source, and if so, extracts the entity encoded, and creates a Principal to add to HTTPServletRequest.
Cookie (Pending Dublin)– This checks for a Cookie, and if present, decodes. If so, it creates a Principal to add to HTTPServletRequest…
BasicAuth – This checks, as you see, the HTTP Servlet Header, but there are various permutations of exactly how it gets there, so there are, unfortunately, several paths that must be accommodated. One of which is the Caching… we don’t want to hit the DB or remote User/Password API (provided by the organization) for the same password over and over, so we need to cache the response, and if it matches exactly, then create the Principal, etc.
Success for Authentication¶
In “raw” Java, the responses can simply be read from the “TAF” (or “EpiTaf”) being used.
- In J2EE, the “CADI Filter” will take positive Authentication and
- # Associate the created Principal to the HTTPServletRequest (available as “getUserPrincipal()” # Add the ability to do Cached Authorizations to HTTPServletRequest (available as “isUserInRole(String s)” (see Authorization Section) # Send to next element in the Filter Chain
Responding to Failed Authentication¶
Finding different kinds of Authentication Schemes and Protocols on an incoming transaction are the relatively easy parts. Responses are a bit harder.
X509 – Just because the TLS doesn’t include a valid and TRUSTED X509 certificate, doesn’t mean it is actually an invalid client certificate and should be rejected. If you did, you would never actually try to find a BasicAuth “Authorization” header. The cert might be from 1 way TLS or 2-way TLS with a valid Client cert, just not one where we can derive the Organizational Identity. In this case, we let the other TAFs handle the return response.
Cookies – Cookies are only designed to work with Browsers. The appropriate response is to redirect the browser to the Organization’s SSO Logon Page, and type in your password on a form, this, of course, cannot be done by a App-to-Apps… Therefore, this is only sent back for Browsers.
BasicAuth – the fallback for App-to-App or when nothing else applies. If all else fails, and there is either a bad password, or there is nothing else to try, we send back a 401. Again, the Cookie Logon “Browser Redirect” takes precedence for Browser traffic, but if Cookie TAF not included or it’s APP to APP, then 401 is returned.
AAF is designed to cover Fine-Grained Authorization, meaning that the Authorizations provided are able to used an Application’s detailed authorizations, such as whether a user may be on a particular page, or has access to a particular Pub-SUB topic controlled within the App.
This is a critical function for Cloud environments, as Services need to be able to be installed and running in a very short time, and should not be encumbered with local configurations of Users, Permissions and Passwords.
To be effective during a computer transaction, Security must not only be secure, but very fast. Given that each transaction must be checked and validated for Authorization and Authentication, it is critical that all elements on this path perform optimally.