You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2012/01/04 18:43:08 UTC
Re: Initial WS-Federation support commited to sandbox
Hi Oli,
Is there a reason why the IDP STS (and the IDP) deploys to Tomcat on
port 9080 instead of 8080? It uses 8080 for the commented out plugin.
> What do you think about this?
It's pretty cool from a security POV. Do you have any plans to look at
supporting the Federation Metadata document? How about sign-out?
Is there much work involved in support the full scenario of having
both resource and requestor STS instances?
Colm.
On Wed, Dec 21, 2011 at 10:20 PM, Oliver Wulff <ow...@talend.com> wrote:
> Hi there
>
> I was working in the last 5 months in enabling tomcat for federation and propagate the security context of the browser user to the back end web services using the CXF STS.
>
> I just committed this code to the cxf sandbox:
> http://svn.apache.org/viewvc/cxf/sandbox/fediz/
>
> This project contains 5 modules:
>
> A) Identity provider (IDP), authentication server
>
> * fediz-idp
> This module is more or less a servlet which processes and transforms the incoming federation message for an STS request
> more information can be found here:
> http://owulff.blogspot.com/2011/10/configure-and-deploy-identity-provider.html
>
> * fediz-idp-sts
> The CXF sts is responsible to issue a SAML token and adding the claims (firstname, lastname, email, roles) to the SAML token
> more information can be found here:
> http://owulff.blogspot.com/2011/10/configure-and-deploy-cxf-25-sts-part-i.html
>
>
> B) Federation plugin for application server
>
> * fediz-core
> This module contains the core logic to validate the federation sign in message. It validates the SAML token. The whole processing is application server agnostic.
>
> * fediz-tomcat
>
> This module implements the Tomcat authenticator and adapts the core federation logic to the Tomcat specific authenticator and establish the jee security context
>
>
> more information can be found here:
>
> http://owulff.blogspot.com/2011/11/configure-tomcat-for-federation-part.html
>
>
> C) Sample application
>
>
> I've planned to add support for Websphere and Pax Web.
>
>
>
> What do you think about this?
>
>
>
> Thanks
>
> Oli
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
AW: Initial WS-Federation support commited to sandbox
Posted by Oliver Wulff <ow...@talend.com>.
Hi Colm
In my testing set up, the web application is deployed into a tomcat instance with port 8080 and the central idp component is deployed into a separated tomcat instance with port 9080. Usually, you have one idp component used by several applications which was the reason to separate that already in the test setup.
I've planned to implement to federation metadata document part in january as it will also ease the integration with Microsoft .NET / Visual Studio also.
After the federation metadata document is implemented I planned to extend the STS and IDP to support requestor and resource STS/IDP. Well, you could also support a chain of IDP instances which is completely transparent to the browser and web application.
Sign-out is not yet in scope. The reason is whether it is really needed that when you sign out in one web application, you should sign out to all other web applications as well.
Thanks
Oli
------
Oliver Wulff
http://owulff.blogspot.com
Solution Architect
Talend Application Integration Division http://www.talend.com
________________________________________
Von: Colm O hEigeartaigh [coheigea@apache.org]
Gesendet: Mittwoch, 4. Januar 2012 18:43
Bis: dev@cxf.apache.org
Betreff: Re: Initial WS-Federation support commited to sandbox
Hi Oli,
Is there a reason why the IDP STS (and the IDP) deploys to Tomcat on
port 9080 instead of 8080? It uses 8080 for the commented out plugin.
> What do you think about this?
It's pretty cool from a security POV. Do you have any plans to look at
supporting the Federation Metadata document? How about sign-out?
Is there much work involved in support the full scenario of having
both resource and requestor STS instances?
Colm.
On Wed, Dec 21, 2011 at 10:20 PM, Oliver Wulff <ow...@talend.com> wrote:
> Hi there
>
> I was working in the last 5 months in enabling tomcat for federation and propagate the security context of the browser user to the back end web services using the CXF STS.
>
> I just committed this code to the cxf sandbox:
> http://svn.apache.org/viewvc/cxf/sandbox/fediz/
>
> This project contains 5 modules:
>
> A) Identity provider (IDP), authentication server
>
> * fediz-idp
> This module is more or less a servlet which processes and transforms the incoming federation message for an STS request
> more information can be found here:
> http://owulff.blogspot.com/2011/10/configure-and-deploy-identity-provider.html
>
> * fediz-idp-sts
> The CXF sts is responsible to issue a SAML token and adding the claims (firstname, lastname, email, roles) to the SAML token
> more information can be found here:
> http://owulff.blogspot.com/2011/10/configure-and-deploy-cxf-25-sts-part-i.html
>
>
> B) Federation plugin for application server
>
> * fediz-core
> This module contains the core logic to validate the federation sign in message. It validates the SAML token. The whole processing is application server agnostic.
>
> * fediz-tomcat
>
> This module implements the Tomcat authenticator and adapts the core federation logic to the Tomcat specific authenticator and establish the jee security context
>
>
> more information can be found here:
>
> http://owulff.blogspot.com/2011/11/configure-tomcat-for-federation-part.html
>
>
> C) Sample application
>
>
> I've planned to add support for Websphere and Pax Web.
>
>
>
> What do you think about this?
>
>
>
> Thanks
>
> Oli
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com