[anil.saldhana]

Point 1:
Actually it does not really matter who does the authentication (SP or IDP) as long as a proper SAML assertion is produced as a federation token. In my opinion, the IDP's sole responsibility is to propagate the federated token to the domain where the user wants to go. Generating the SAML token would be the responsibility of the entity that performs the actual authentication (SP or IDP) depending on how you want to split the concerns.

Point 2:
local authentication results not producing a federated token would limit the use of SSO even though specs like SAML exists to support cross domain federation to some extent. Having a central IDP doing the authentication will work just fine for internal websites. However, thats just half the battle. There is definitely market value in our customers' website being able to do local authentication, producing a SAML assertion that is compatible with their partner sites like salesforce.com. Its obvious that asking SalesForce.com to hook into your company's IDP for authentication is definitely not feasible.

To answer your point 1, as I peruse the SAML 2.0 front, I see that when it comes to federated authentication, it is always the IDP that does it.

To answer your point 2, what I was saying is within a particular circle of trust, an idp can exist that takes care of all the authentication. Between circles of trusts, there can be IDPs transporting saml. So salesforce has an idp service that is capable of federating identity onto the JBoss idp (which is internally used to make the authentication decisions).

I think what I am talking about is centralized authentication within a domain and what you are saying is true federation with decentralized authentication within a domain. Again I think this is an architecture deployment decision.

[starksm64]

Regarding the decrentralized authentication, it should be possible. It requires that one incorporates an authentication aspect that introduces the required level of trust validation. That could be done via chaining of login modules. One simple example would be an additional login module that signed the authenticated subject. This would provide no validation that the authentication result was actually valid, just that the server configuration is one that has access to a cert we trust. I need to look at the mechanisms WS-Trust promotes.

[soshah]

I think what I am talking about is centralized authentication within a domain and what you are saying is true federation with decentralized authentication within a domain. Again I think this is an architecture deployment decision.

Actually it seems like the issue is at what point the central authentication mechanism (IDP in this case) is plugged in. I think integration at the presentation tier using redirects to a central login page served by the IDP is a bit clunky, but its one way of doing it and should be certainly provided as a choice.

However, I would also like to be able to keep my exact same "Login" page from a presentation perspective and hook in to the central IDP within my "Login JAAS Module" while I am actually processing the login request. Kind of like integration at the controller layer.

This leads to a much better user experience and would make SSO pretty much transparent to the user.

[starksm64]

Yes, FORM and BASIC auth have to work as is. I think we will have to modify the base tomcat authenticator classes to properly integrate the exteralization of the authentication mechanism, including validating a token, renewing a token, etc. independent of the standard authentication mechanism. Even custom authentication mechanisms such as commonly used with struts need to be considered. One current problem with a struts type of custom login is that is does not integrate well into the servlet container standard auth in terms of request.getUserPrincipal, isUserInRole as well as propagation. Since we will be mucking with the authentication layer, I also want to look into a better integration api that allows application level initiated authentication to result in an expierence similar to the container managed authentication.

[anil.saldhana]

So, there it is. Any discussion of a generic authentication layer cannot be done until we make the tomcat base authenticator classes aware of the external authentication semantics weaved into the container. I was trying to see ways to avoid this mucking of the tomcat inbuilt authentication framework, but seems inevitable.

Thanks Sohil and Scott for the discussion....

Are there any feedback points from the general observers in the public???

[starksm64]

Mucking will certainly be required.

[anil.saldhana]

Ok, it is not as bad as I thought. There is an opportunity to override the authenticators that we can use for the various authentication modes - basic,digest,client-cert etc.

The authenticators get configured in
http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Class is final...

And the properties file that allows us to plug in our own authenticators that
can engulf the regular auth behavior + notion of federation or any custom behavior, is:
http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/Authenticators.properties

I have not tested this yet.

$>cd deploy/jbossweb-tomcat55.sar
$> jar tvf catalina.jar
306 Fri Sep 23 09:40:46 CDT 2005 org/apache/catalina/startup/Authenticators.properties
 .....
 1025 Fri Sep 23 09:40:44 CDT 2005 org/apache/catalina/startup/ContextConfig$ContextErrorHandler.class
 24663 Fri Sep 23 09:40:44 CDT 2005 org/apache/catalina/startup/ContextConfig.class

Scott, thoughts?

[starksm64]

I do not like how the default authenticators are configured via a properties file. It needs to be mbeanized such that we can eternalize and override these settings at the web container level as well as the web deployment.

[anil.saldhana]

Configuring the authenticators at the context level is possible via JMX.

I want to summarize the discussion we have had till now. Please feel free to add your comments or correct me:

Web Application that does only federation and no standard http auth mechanism:
==============================================
A custom valve that does federated identity redirect and saml consumption can be configured at the context level.

Web Applications that do Basic, Form, Digest, Client-Cert Authentication:
==============================================
Allow them to gather the authentication information in the regular way. Today the authenticators gather the authentication credentials and then call the realm to authenticate the user providing the credentials (either username/password or certs etc). So in theory, we have the liberty to do whatever mechanism we want to apply to authenticate/authorize via the realm with the identity information gathered by the authenticator. We can plugin a jaas framework here with a set of chained login modules that can work on the credentials including dealing with federation, token renewal, custom http headers based auth etc can be done.
If this is correct, then the mucking of the tomcat basic authenticators will involve gathering of authentication information needed by the ultra-smart-configured realm, needs to be done. The collection will involve domain cookies, user entered information etc. Once all the information is gathered about the user agent by the base authenticator and passed to the realm, it is upto the chain of configurable auth modules plugged in the realm to do the authentication/authorization.

[anil.saldhana]

http://jira.jboss.com/jira/browse/JBAS-2283
a need for custom header based authentication.....