cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Wulff <owu...@talend.com>
Subject RE: Fediz IDP refactored
Date Thu, 24 Jan 2013 20:57:45 GMT
btw, this is my google talk id:
ownaish

Thanks

________________________________________
From: Beucher Thierry [thierry.beucher@atos.net]
Sent: 21 January 2013 13:12
To: dev@cxf.apache.org
Subject: RE: Fediz IDP refactored

Hi Oliver,

Below my answer to your question about difference between IDP and IDP Remote.
About yours interesting suggestions related to ApplicationService Bean and IDP configuration
GUI I plan to have a meeting with Juan Manuel Cabrera as soon as possible.

In my delivery IDP/STS and IDP/STS Remote are not quite different.
I only attempted to provide a starting point to illustrate
§ 13.3 Detailed Example of Web Requester Syntax of  http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175002

Besides, I would be very interested if you could validate this point.

For me, IDP/STS Remote is nothing more than the requestor's IDP/STS owning the Identity of
the requestor user. The difference is only matter of configuration.
Assuming the request to the resource IDP/STS is done by a requestor user related to a different
home realm (see 'passwords.xml' and 'userClaims.xml' in 'fediz-idp-sts-remote' project), there
are two use cases :
*       The requestor's browser doesn't add the 'whr' parameter to the request : the resource
RP redirects to the resource IDP/STS to ask the user for selecting his/her home realm (specification
§ 13.3 step 3.1); this is done in fediz-idp project's 'signinform.jsp' and based on 'idpPartnersUrls'
list bean in 'IDPPartners.xml',
*       The requestor's browser adds the 'whr' parameter to the request : the resource RP
can directly redirect to the requestor IDP/STS in order to fill credentials (specification
§ 13.3 step 5.1).
I nevertheless draws attention to the fact that there is still no integration tests for this
feature.

Finally, do you think this forked delivery is eligible, as such, for a "pull request"?

Regards

-----Message d'origine-----
De : Oliver Wulff [mailto:owulff@talend.com]
Envoyé : dimanche 20 janvier 2013 15:34
À : dev@cxf.apache.org
Objet : RE: Fediz IDP refactored


Hi Thierry

This looks really good.

What is the difference between IDP and IDP remote?

I think we should improve our configurations around the RPClaims.xml. What do you think about
introducing an ApplicationService Bean where you can reference (file://, http://) a WS-Federation
Metadata document where either the information from the Fediz Plugin is loaded (signature
validation), or a local metadata document can be loaded. Properties which are not covered
by WS-Federation Metadata are set a setter/getters in the ApplicationServiceBean (ex. tokenType,
encryptToken, default home realm, etc).

This leads to another question. Right now, everything is configured in spring configuration
files where the following actions require a restart of the idp/sts:
- add a new application
- add a new trusted IDP (like configure a new requestor idp in the resource idp)
- etc.
I was thinking that a GUI for the IDP would be really nice where you can configure the applications
etc. As the spring configuration is static, we could store this information in a database
and add it to the spring context dynamically during startup and after a change. Of course,
some part are related to the STS as well.

Thanks
Oli

------

Oliver Wulff

Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com

Talend Application Integration Division http://www.talend.com

________________________________________
From: Beucher Thierry [thierry.beucher@atos.net]
Sent: 18 January 2013 17:29
To: dev@cxf.apache.org<mailto:dev@cxf.apache.org>
Subject: RE: Fediz IDP refactored

Hi all,

Thanks for your remarks.

As Dan suggested, I have forked from https://github.com/apache/cxf-fediz to https://github.com/tbrgit/cxf-fediz
last night (then after Colm commit # ef9a0fe5b8fecea18cce0eec3f2116e4aa51663f)

Below is the brief summary of changes and enhancements compared to first draft patch delivery
:

*       Missing legal headers added
*       Compliance with Checkstyle and PMD rules
*       Useless SafeDispatcherServlet class Oliver pointed me out removed
*       Major refactoring of federation-webflow.xml
*       Chained protocol-oriented checks decision states have been merged in one
*       <transitions on-exception ... /> have been reviewed
*       The whole now runs with integration tests (Jetty and Tomcat) for BASIC authentication
*       with refactoring of systests-jetty8 pom.xml --> maven-dependency-plugin 'unpack'
goal instead of 'copy'  to be compliant with  systests-tomcat7
*       with minor changes to systests-jetty8 jetty/idp-server.xml and jetty/rp-server.xml
 --> to be equivalent to systests-tomcat7 target structure
*       bug related to http return code 500 which should be 401 is fixed on my side (@Ignore
uncommented)
*       Note: I plan to add corresponding integration tests for FORM authentication

More, as "a cherry on the cake", this forked delivery contains a starting point for "full"
federation by supporting WS Federation 'whr' query parameter :
*       which could be directly provided by the remote/requestor browser,
*       or selected by the remote user in local/resource IDP's 'signinform.jsp' (among available
partners realms registered : see 'IDPPartners.xml' file) if not provided.
On RP side, this feature requires a 'HomeRealmCallbackHandler' class (provided in this delivery)
configured in 'fediz_config.xml'  to intercept the 'whr' query parameter.
It works on my side but currently I have not added dedicated integration tests.

Have all a good WE !

-----Message d'origine-----
De : Daniel Kulp [mailto:dkulp@apache.org] Envoyé : lundi 14 janvier 2013 21:48 À : dev@cxf.apache.org<mailto:dev@cxf.apache.org>;
Oliver Wulff Objet : Re: Fediz IDP refactored



On Jan 14, 2013, at 3:41 PM, Oliver Wulff <owulff@talend.com<mailto:owulff@talend.com<mailto:owulff@talend.com<mailto:owulff@talend.com>>>
wrote:

> Hi there
>
> I had a look into it and it looks to be a really good starting point. As you wrote, it
is not yet complete.
>
> But there is still a lot of stuff to do. Due to the fact that you and maybe some others
will have to commit updates to it it might be easier to have a mirror a github thus you can
commit as well. When it is close to be complete I can merge it into the idp project at apache.

Yep.   All that CXF projects have git mirrors at Github already:
https://github.com/apache/cxf-fediz

that you can fork from.   Also, if you issue a "pull request", the notice should get sent
right to this list at which point we can review and pull if appropriate.

Dan



> Could you add the missing licensing header? Make the modifications to the idp project
itself thus the maven checkstyle are validated as there are some formatting issues. Not sure
about SafeDispatcherServlet as it looks to be from CAS.
>
> What do you think?
>
> I would also like to incorporate spring-security into it thus we can leverage the existing
authentication mechanisms provided by it. But one step after the other.
>
> Thanks
> Oli
>
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> From: Oliver Wulff [owulff@talend.com]
> Sent: 08 January 2013 20:20
> To: dev@cxf.apache.org<mailto:dev@cxf.apache.org<mailto:dev@cxf.apache.org<mailto:dev@cxf.apache.org>>
> Subject: RE: Fediz IDP refactored
>
> Thanks Thierry. I'll look into this asap.
>
> Oli
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> From: Beucher Thierry [thierry.beucher@atos.net]
> Sent: 08 January 2013 17:52
> To: dev@cxf.apache.org<mailto:dev@cxf.apache.org<mailto:dev@cxf.apache.org<mailto:dev@cxf.apache.org>>
> Subject: RE: Fediz IDP refactored
>
> A new post about 'Fediz IDP refactored with Spring Web Flow' has been added to Fediz
JIRA repository.
> at https://issues.apache.org/jira/browse/FEDIZ-41
>
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif
de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous
recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire.
L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos
ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts
soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne
aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout
dommage résultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely for the addressee;
it may also be privileged. If you receive this e-mail in error, please notify the sender immediately
and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot
be triggered for the message content. Although the sender endeavours to maintain a computer
virus-free network, the sender does not warrant that this transmission is virus-free and will
not be liable for any damages resulting from any virus transmitted.

--
Daniel Kulp
dkulp@apache.org<mailto:dkulp@apache.org<mailto:dkulp@apache.org<mailto:dkulp@apache.org>>
- http://dankulp.com/blog Talend Community Coder - http://coders.talend.com



  ________________________________

Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de
ses destinataires. Il peut également être protégé par le secret professionnel. Si vous
recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire.
L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos
ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts
soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne
aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout
dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee;
it may also be privileged. If you receive this e-mail in error, please notify the sender immediately
and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot
be triggered for the message content. Although the sender endeavours to maintain a computer
virus-free network, the sender does not warrant that this transmission is virus-free and will
not be liable for any damages resulting from any virus transmitted.



  ________________________________

Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de
ses destinataires. Il peut également être protégé par le secret professionnel. Si vous
recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire.
L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos
ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts
soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne
aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout
dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee;
it may also be privileged. If you receive this e-mail in error, please notify the sender immediately
and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot
be triggered for the message content. Although the sender endeavours to maintain a computer
virus-free network, the sender does not warrant that this transmission is virus-free and will
not be liable for any damages resulting from any virus transmitted.
Mime
View raw message