AW: Bug 51334 - Federation support for Tomcat
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 : >>>> > 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
AW: AW: AW: Bug 51334 - Federation support for Tomcat
>>> 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? >>> 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 t
AW: AW: Bug 51334 - Federation support for Tomcat
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. 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. Therefore, I think we can get better confidence from potential customers if the federation plugin is provided as part of Tomcat extras module. I'll accept your decision and proceed with that. Thus let me know what the next steps are. Thanks Oliver Von: Mark Thomas [ma...@apache.org] Gesendet: Dienstag, 18. Oktober 2011 10:54 Bis: Tomcat Developers List Betreff: Re: AW: Bug 51334 - Federation support for Tomcat On 17/10/2011 15:29, Oliver Wulff wrote: > Hi Mark > > Thanks for your quick feedback... > > There are two pieces - IDP and authenticator - where we have to > decide how to package this. > >>>> > Given that Tomcat doesn't support web services out of the box, I > don't think it makes sense to ship WS-Federation as part of the > standard Tomcat distribution. That rules out option 1 in my view. >>>> > WS-Federation doesn't address federation to web services only. > WS-Federation describes an active requestor profile (which is for web > service clients/providers) and a passive requestor profile (which is > for sso for web applications). The patch I applied is for the later. OK. Understood. > That leaves 2 or 3. I remain to be convinced that there is any > demand for this functionality. I haven't seen any evidence (questions > on the users list, bugs raised in Bugzilla) that folks are using the > JSR-109 support in the extras package so I find it hard to see how > there would be much demand for WS-Federation >>>> > As mentioned above WS-Federation passive requestor profile doesn't > relate to web services and JSR-109 at all. Instead it gives the > tomcat community a great added value for enterprise web applications > where authentication is externalized to another site and provides the > basis to implement claims based authorization. This kind of > funtionality does further enable users to use Tomcat in the cloud but > keep the authentication within the company. > > Considering this, I'd prefer to go with option 2 (extra tomcat > module). 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. If we were seeing the same number of references to WS-Federation on the users mailing list as we see for SecurityFilter then option 2 would be a no brainer. Given that the key here is building up a community of users, another possibility would be to go via the Apache incubator. Mark - 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
AW: Bug 51334 - Federation support for Tomcat
Hi Mark Thanks for your quick feedback... There are two pieces - IDP and authenticator - where we have to decide how to package this. >>> Given that Tomcat doesn't support web services out of the box, I don't think it makes sense to ship WS-Federation as part of the standard Tomcat distribution. That rules out option 1 in my view. >>> WS-Federation doesn't address federation to web services only. WS-Federation describes an active requestor profile (which is for web service clients/providers) and a passive requestor profile (which is for sso for web applications). The patch I applied is for the later. I've extended the current FormAuthenticator class. The key difference is that the FormAuthenticator does a forward to another location to challenge the user to enter username/password whereas the FederationAuthenticator redirects the browser to another web site which is called the IDP. The IDP sends a hidden form back to the browser which will be automatically submitted. This HTTP POST contains the security token which is validated by the FederationAuthenticator and creates a FederationPrincipal which extends from GenericPrincipal and provides the user, roles and claims (as part of FederationPrincipal). This allows the application developer to use the standard servlet api to get the current principal, check for roles and if the application is claims based they can downcast to FederationPrincipal. >>> That leaves 2 or 3. I remain to be convinced that there is any demand for this functionality. I haven't seen any evidence (questions on the users list, bugs raised in Bugzilla) that folks are using the JSR-109 support in the extras package so I find it hard to see how there would be much demand for WS-Federation >>> As mentioned above WS-Federation passive requestor profile doesn't relate to web services and JSR-109 at all. Instead it gives the tomcat community a great added value for enterprise web applications where authentication is externalized to another site and provides the basis to implement claims based authorization. This kind of funtionality does further enable users to use Tomcat in the cloud but keep the authentication within the company. Considering this, I'd prefer to go with option 2 (extra tomcat module). Regards Oliver Von: Mark Thomas [ma...@apache.org] Gesendet: Montag, 17. Oktober 2011 13:10 Bis: Tomcat Developers List Betreff: Re: Bug 51334 - Federation support for Tomcat On 17/10/2011 09:22, Oliver Wulff wrote: > Hi guys > > I've attached an initial version of the patch for the following > bugzilla task: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=51334 > > I'd like to initiate a discussion how to bundle and integrate this > into tomcat. I've added a comment to the attachment which is listed > at the bottom of this mail. I see four options. 1. Include this in the standard Tomcat distribution. 2. Ship this as a Tomcat extras module. [1] 3. Distribute this from Apache extras. [2] 4. Ship this from a.n.other code hosting service (Google code, source forge etc.) Given that Tomcat doesn't support web services out of the box, I don't think it makes sense to ship WS-Federation as part of the standard Tomcat distribution. That rules out option 1 in my view. Since I always view option 3 as better than option 4, that rules out option 4 in my view. That leaves 2 or 3. I remain to be convinced that there is any demand for this functionality. I haven't seen any evidence (questions on the users list, bugs raised in Bugzilla) that folks are using the JSR-109 support in the extras package so I find it hard to see how there would be much demand for WS-Federation. With this in mind, I'm currently leaning towards option 3 but with links being added to the WS-Federation implementation in the standard Tomcat docs (much the same way we did with Waffle and friends for Windows auth integration). If we do see clear demand for this being shipped with Tomcat then it could move to a Tomcat extras module if everyone involved was happy with such a move. Mark [1] http://tomcat.apache.org/download-70.cgi [2] http://code.google.com/a/apache-extras.org/hosting/ > > The maven module wsfed-tomcat contains a custom authenticator called > FederationAuthenticator. There are more information in > docs/readme.txt how to configure it. > > To test this piece of functionality you need a third party component > which is the IDP. Technically, the IDP is a web application. There > some more information on the IDP here: > > http://owulff.blogspot.com/2011/10/configure-and-deploy-identity-provider.html > > (There is a unit test to test the federation logic in wsfed-core > which doesn't need a servlet container up and running in > wsfed-core/src/test/java//Fede
Bug 51334 - Federation support for Tomcat
Hi guys I've attached an initial version of the patch for the following bugzilla task: https://issues.apache.org/bugzilla/show_bug.cgi?id=51334 I'd like to initiate a discussion how to bundle and integrate this into tomcat. I've added a comment to the attachment which is listed at the bottom of this mail. The maven module wsfed-tomcat contains a custom authenticator called FederationAuthenticator. There are more information in docs/readme.txt how to configure it. To test this piece of functionality you need a third party component which is the IDP. Technically, the IDP is a web application. There some more information on the IDP here: http://owulff.blogspot.com/2011/10/configure-and-deploy-identity-provider.html (There is a unit test to test the federation logic in wsfed-core which doesn't need a servlet container up and running in wsfed-core/src/test/java//FederationProcessorTest.java). The IDP is just a servlet which delegates main of the functionality to the STS (SecurityTokenService) which is capable to issue any kind of security tokens like SAML 2.0. The IDP is completely apache licensed (CXF 2.5 STS, WSS4J, OpenSAML). I need your advice what the options are to provide the IDP because it should not be part of the tomcat distribution itself. Maybe a separate downloadable file or just a blog? I also see an opportunity that the IDP could be enhanced further thus it can be used within enterprises and support more authentication options than just username/password (ex. kerberos). Looking forward for your feedback. Regards Oliver >>> I've attached a complete maven project which consists of the following modules: - wsfed-core this is the core federation funtionality which is servlet container agnostic - wsfed-tomcat this is the adaption of the wsfed-core component for tomcat implemented as an authenticator - wsfed-tomcat-example this is the sample web application where federation is enabled. This example must be deployed into a tomcat container which contains the above library and dependencies in wsfed-core and wsfed-tomcat. WS-Federation depends on a third party security component called Identity Provider (IDP). I've posted a blog which explains this in more detail. The Identity Provider is responsible to authenticate a user and a security token which is handled by an STS. The following two modules provide the IDP functionality: - wsfed-idp this is the IDP component which is required for a web application which has federation enabled. For more information check this out: http://owulff.blogspot.com/2011/10/configure-and-deploy-identity-provider.html - wsfed-idp-sts this is the STS component which is used by the idp. For more information check this out: http://owulff.blogspot.com/2011/10/configure-and-deploy-cxf-25-sts-part-i.html >>>
Antwort: Re: Passive Requestor Profile WS-Federation contribution
I've raised the following "bug" (enhancements): https://issues.apache.org/bugzilla/show_bug.cgi?id=51334 Mark Thomas An Tomcat Developers List 06/07/2011 11:27 AM Kopie Thema Bitte antworten Re: Passive Requestor Profile an WS-Federation contribution "Tomcat Developers List" On 07/06/2011 07:28, Oliver Wulff wrote: > > src="http://zdownload.zurich.com/mailimages/ZHP_MailHeader.gif"; /> > > Hi there > > I'd like to extend Tomcat to support the Passive Requestor Profile of > WS-Federation and contribute this to the community. > > What is the approach I should proceed? Shall I log JIRA and apply the > "patch" there? Tomcat uses Bugzilla, not Jira but apart from that, that is the right approach. Based on a quick glance at Wikipedia, this looks like something that belongs in a library that would be packaged with an application. On that basis, it is unlikely to be included with Tomcat. It is prefectly possible I have misunderstood the purpose of this so be sure so include some info in the BZ ticket as to why it is a good idea to have this in Tomcat by default. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org *** BITTE BEACHTEN *** Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet möglicherweise vertrauliche oder gesetzlich geschützte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter Ausschluss jeder Reproduktion zu zerstören und die absendende Person umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Antwort: Re: Passive Requestor Profile WS-Federation contribution
Hi Mark WS-Federation Passive Requestor Profile is part of the authentication mechanism within a servlet engine/app server and not part of the web application. http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf (section 13) Tomcat provides builtin support for Form based authentication and different kind of authentication backends (Realms). The described solution is just another way for authentication and authorization support (roles). Do you agree? Thanks Oliver Mark Thomas An Tomcat Developers List 06/07/2011 11:27 AM Kopie Thema Bitte antworten Re: Passive Requestor Profile an WS-Federation contribution "Tomcat Developers List" On 07/06/2011 07:28, Oliver Wulff wrote: > > src="http://zdownload.zurich.com/mailimages/ZHP_MailHeader.gif"; /> > > Hi there > > I'd like to extend Tomcat to support the Passive Requestor Profile of > WS-Federation and contribute this to the community. > > What is the approach I should proceed? Shall I log JIRA and apply the > "patch" there? Tomcat uses Bugzilla, not Jira but apart from that, that is the right approach. Based on a quick glance at Wikipedia, this looks like something that belongs in a library that would be packaged with an application. On that basis, it is unlikely to be included with Tomcat. It is prefectly possible I have misunderstood the purpose of this so be sure so include some info in the BZ ticket as to why it is a good idea to have this in Tomcat by default. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org *** BITTE BEACHTEN *** Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet möglicherweise vertrauliche oder gesetzlich geschützte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter Ausschluss jeder Reproduktion zu zerstören und die absendende Person umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Passive Requestor Profile WS-Federation contribution
http://zdownload.zurich.com/mailimages/ZHP_MailHeader.gif"; /> Hi there I'd like to extend Tomcat to support the Passive Requestor Profile of WS-Federation and contribute this to the community. What is the approach I should proceed? Shall I log JIRA and apply the "patch" there? Thanks Oliver *** BITTE BEACHTEN *** Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet möglicherweise vertrauliche oder gesetzlich geschützte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter Ausschluss jeder Reproduktion zu zerstören und die absendende Person umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
