Hello, Even if it's a good addition, I understand the fact about not integrate this in the standard Apache Tomcat distribution (option 1) to prevent having too huge distribution with some new external dependencies.
2011/10/19 Oliver Wulff <owu...@talend.com>: >>>> > I get the impression, rightly or wrongly, that this is an attempt to to get a > jump > start for a little used SSO solution by getting it included in the > Tomcat build. That isn't the way the ASF works. >>>> > This is not the case. It's the other way around. The federation plugin should > help Tomcat to better compete with the big closed source solutions by > supporting an industry standard. In constrast to buy and integrate a security > product where you have to deploy custom agents to all sort of containers to > be able to integrate with the centrally running security component (usually > the communication between the agents and the central security component is > proprietary). > > What would be the next steps to go with Apache Extras? Here we/I can help you for project creation etc... I just wonder about the package names to use and maven coordinate. Not sure if Apache extras stuff can use org.apache.* namespace especially for maven deployment in this groupId org.apache.* . (org.apache.extras.* ?) What can we use ? org.talend.tomcat.extras ? > >>>> > This is not my decision, it is the community's decision. I am just one > voice in that community with a tendency to state an opinion given the > opportunity. You need to convince the community that this is worth > doing. Actually, that isn't strictly true. Since this is a code change > any committer could veto it. I'd suggest leaving it a few days to see if > any of the other committers comment. >>>> > +1 > > Thanks > Oliver > ________________________________________ > Von: Mark Thomas [ma...@apache.org] > Gesendet: Mittwoch, 19. Oktober 2011 16:41 > Bis: Tomcat Developers List > Betreff: Re: AW: AW: Bug 51334 - Federation support for Tomcat > > On 19/10/2011 15:16, Oliver Wulff wrote: >> Hi Mark >> >>>>> >> The lack of demand argument applies equally to WS-Federation >> considered in isolation. I'd like to see that there was at least some >> traction behind this in the Tomcat community before going with option >> 2. >>>>>> >> I understand where you're coming from. >> >> IMHO, the federation functionality gives a lot of added value to >> tomcat for being able to support single sign across within an >> enterprise as well as across enterprises or in the cloud. Thus tomcat >> can even better compete with big application servers because you get >> enterprise SSO only by also using the identity suite. > > There are plenty of other SSO options out there that ship with the > necessary modules for Tomcat. That, combined with the minimal interest > in WS-Federation seen in the community to date, makes me think that a > separate project is the right place for this. It is a model that has > worked well for many SSO solutions for a number of years. > > There have been preliminary discussions about merging SecurityFilter > into the Tomcat code base as it is so widely used but that discussion > died down without anything happening. And I am fine with that. > > Personally I think something needs to be as widely used as > SecurityFilter before we even think about adding it to the Tomcat code > base. The Tuckey UrlRewriteFilter is another component that gets used > often enough that I'd be happy to see it added to the code base. I'll > add at this point I am just using these as examples. I am *not* > suggesting that these projects to be borged by the Tomcat project. If > they choose to approach us, I am sure we'd listen carefully to their > proposals. > >> Very often, big enterprises uses Microsoft Active Directory (which >> includes the federation IDP (ADFS)) to authenticate their users which >> includes ADFS. The federation plugin can integrate with ADFS >> out-of-the-box - not yet tested. Thus, you get SSO within your >> enterprise without deploying another identity suite with your tomcat >> based applications. > > If the enterprise is using Microsoft AD then Tomcat can plug directly > into that via the built-in Kerberos support. See [1]. The addition of > that feature had the right balance of user demand and minimal code > additions / changes to Tomcat. > >> Therefore, I think we can get better confidence from potential >> customers if the federation plugin is provided as part of Tomcat >> extras module. > > That is not a sufficient reason to add it to the build. I get the > impression, rightly or wrongly, that this is an attempt to to get a jump > start for a little used SSO solution by getting it included in the > Tomcat build. That isn't the way the ASF works. > > Every feature added to Tomcat is considered (informally) in terms of: > - user demand > - additional code added > - changes that might break other stuff > - ease of maintenance > > When I measure WS-Federation against these criteria it does not reach > the threshold I think it needs to meet in order to get included in > either the core distribution or as a bundled extra. > >> I'll accept your decision and proceed with that. Thus let me know >> what the next steps are. > > This is not my decision, it is the community's decision. I am just one > voice in that community with a tendency to state an opinion given the > opportunity. You need to convince the community that this is worth > doing. Actually, that isn't strictly true. Since this is a code change > any committer could veto it. I'd suggest leaving it a few days to see if > any of the other committers comment. > > Mark > > [1] http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
