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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
