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 webflow
Date Wed, 14 Aug 2013 21:08:20 GMT
Hi Thierry

I committed the patch here:
http://svn.apache.org/viewvc?view=revision&revision=1514048

Thanks a lot for your contribution.

a) and d) are fixed (based on your patch).

b) and c) is pending. Can you provide me a patch file based on the new trunk version?

I'd like to clean up the author tag as it is usually rarely used.

Do you have some time to work on more unit tests for the IDP itself (not systests which requires
the helloworld application and fediz plugin as well deployed in a container)?

I'd like to get out the release 1.1.0 within the next two/three weeks.

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 August 2013 13:13
To: dev@cxf.apache.org
Subject: RE: Fediz IDP webflow

Hi Thierry

>>>
1.      On my side bob has roles user,manager,admin with profile 'realms', not User,Manager,Admin.
Therefore request with this user fails with Status 403 because fedizhelloworld is configured
with security role User...
>>>
I've fixed this in the patch applied.

index 4fb594c..eb2822c 100644
--- a/services/sts/src/realms/webapp/WEB-INF/userClaims.xml
+++ b/services/sts/src/realms/webapp/WEB-INF/userClaims.xml
@@ -36,7 +36,7 @@
   <entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
    value="bobwindsor@realma.org" />
   <entry key="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"
-   value="user,manager,admin" />
+   value="User,Manager,Admin" />
  </util:map>


>>>
It doesn't append on my side. I restored the old/normal behavior (fields type="text" to "hidden")
in the fediz-idp-2013-07-23.patch attached to FEDIZ-3. Did you unapplied my previous intermediate
patch before applying the latest (fediz-idp-2013-07-23.patch) ? Last patch should be applied
basing on trunk.
>>>
I fixed this now.

>>>
Same remark that for d). In fediz-idp-2013-07-23.patch, I no longer add cookie on entry of
state checkIsThisIDP but now cookie is only added 1) at showIDPList.submit transition and
2) at transition from  processHRDSExpression but not at transition from checkWHRInSigninRequest.
Therefore home realm is not updated.
>>>
Need to check. I'd like to get the patch committed as soon as possible to have a new base
in trunk to continue the collaboration.

>>>
I have 2 questions back :
1.      Do you validate the tokens chain (Logging was enhanced to make it easier) as is ?
IDP_TOKEN B --> RP_TOKEN for A (obo) - - wresult - - > RP_TOKEN for A --> new IDP_TOKEN
A  --> RP_TOKEN for Fedizhelloworld (obo) - - wresult - - > RP_TOKEN for Fedizhelloworld
(obo)
>>>
I'm kind of lost. What do you mean?

>>>
2.      Did you test also the RP freshness requirement (before and after 1 minute of IDP token
life duration : <freshness>1</freshness> in fediz_config.xml) with local authentication
and freshness requirement propagation with remote authentication ?
>>>
No, I haven't.

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@worldline.com]
Sent: 25 July 2013 09:46
To: dev@cxf.apache.org
Subject: RE: Fediz IDP webflow

Hi Oli,

Thanks for your feedback.

Issues you have discovered :

b) If I choose realm B (redirect to remote idp happens), the wctx is used. The form posted
to the rp contains the wctx with the same value. After the wctx has been posted to the IDP,
it must be cleared.

You are right, it must be cleared. I planned to fix.

c) If you now clear the cookie with rp, you get redirected and the wctx is still sent to the
RP but empty this time.

I will check the wctx's whole lifecycle when fixing b).

d) the auto submit form is now displayed in the browser (should be disabled by default but
the option to enable it for debug purposes would be fine)

It doesn't append on my side. I restored the old/normal behavior (fields type="text" to "hidden")
in the fediz-idp-2013-07-23.patch attached to FEDIZ-3. Did you unapplied my previous intermediate
patch before applying the latest (fediz-idp-2013-07-23.patch) ? Last patch should be applied
basing on trunk.

a) If you have chosen a home realm, it is stored in a cookie for this idp (bound to hostname
and uri). If the rp defines a home realm (whr parameter in signin request), the home realm
is updated. It must not be the case, that an application can overwrite the home realm of a
user. An application can just enforce a home realm for the login for this application but
this must not have an impact for all other applications. Therefore home realm must not be
updated.

Same remark that for d). In fediz-idp-2013-07-23.patch, I no longer add cookie on entry of
state checkIsThisIDP but now cookie is only added 1) at showIDPList.submit transition and
2) at transition from  processHRDSExpression but not at transition from checkWHRInSigninRequest.
Therefore home realm is not updated.

I have 2 questions back :

1.      Do you validate the tokens chain (Logging was enhanced to make it easier) as is ?
IDP_TOKEN B --> RP_TOKEN for A (obo) - - wresult - - > RP_TOKEN for A --> new IDP_TOKEN
A  --> RP_TOKEN for Fedizhelloworld (obo) - - wresult - - > RP_TOKEN for Fedizhelloworld
(obo)

2.      Did you test also the RP freshness requirement (before and after 1 minute of IDP token
life duration : <freshness>1</freshness> in fediz_config.xml) with local authentication
and freshness requirement propagation with remote authentication ?

I have also 1  remark of detail :

1.      On my side bob has roles user,manager,admin with profile 'realms', not User,Manager,Admin.
Therefore request with this user fails with Status 403 because fedizhelloworld is configured
with security role User...

Thanks

Thierry



  ________________________________

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? de Worldline 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 Worldline 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