Hi all I was looking into apache extras and noticed the following statement: >>> Projects hosted on Apache Extras are not considered official Apache Software Foundation projects and they are also not associated, allied, or otherwise organizationally related to The Apache Software Foundation. Therefore, we require project owners to respect the Apache Software Foundation trademark policy, including 1) not using Apache or an existing Apache project name in your Apache Extras project name, and 2) not using org.apache as the prefix for your bundle or package name. In general, projects hosted on Apache Extras must not portray themselves as official Apache Software Foundation projects. >>>
I was not aware that these projects have no correlation to the apache projects. Thus, I see the following todo's: - refactor the code because I used org.apache.catalina... - create a new project at apache extras - description and link to the project on the apache tomcat site (what shall I provide?) - post a message to us...@tomcat.apache.org (APL 2.0 is already used). Anything else? One comment on this: > 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. This is possible but I'd choose the federation approach for the following reasons: - authentication is externalized to the IDP (reduces complexity for tomcat, especially with kerberos) - users and tomcat can run (not a must) in the same kerberos realm or use another authentication mechanism with no exposue to the Tomcat container and app - role and other user information can be provided as part of the issued security token (ex. SAML 1.1, SAML 2.0, ...) Thanks Oli ________________________________________ Von: Olivier Lamy [ol...@apache.org] Gesendet: Freitag, 21. Oktober 2011 09:15 Bis: Tomcat Developers List Betreff: Re: AW: AW: Bug 51334 - Federation support for Tomcat 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
