You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Oliver Wulff <ow...@talend.com> on 2011/10/17 10:22:46 UTC
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
>>>
Re: AW: AW: Bug 51334 - Federation support for Tomcat
Posted by Olivier Lamy <ol...@apache.org>.
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 <ow...@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 [markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
AW: AW: AW: Bug 51334 - Federation support for Tomcat
Posted by Oliver Wulff <ow...@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?
>>>
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 [markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: AW: AW: Bug 51334 - Federation support for Tomcat
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
AW: AW: Bug 51334 - Federation support for Tomcat
Posted by Oliver Wulff <ow...@talend.com>.
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 [markt@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.
<snip/>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: AW: Bug 51334 - Federation support for Tomcat
Posted by Mark Thomas <ma...@apache.org>.
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.
<snip/>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
AW: Bug 51334 - Federation support for Tomcat
Posted by Oliver Wulff <ow...@talend.com>.
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 [markt@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/..../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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug 51334 - Federation support for Tomcat
Posted by Mark Thomas <ma...@apache.org>.
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/..../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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org