Trying to figure out how to dance with Shibboleth, CAS, Liferay and CXF Web Services

[Baptiste Grenier]

Dear Scott,

(Cross posted-to users@ where it was posted first...)

Le 11/01/13 à 15:15, Cantor, Scott téléscripta :
> On 1/11/13 6:18 AM, "Baptiste Grenier" <bgrenier at maatg.fr> wrote:
> >
> >We tried to store the SAML assertion returned by the IdP in the user
> >profile and use it to query the Web Service, it works but as the SAML is
> >short-lived it is problematic.
> 
> It's not valid in many ways. The SSO assertion is not meant for use by any
> service other than the SP. If you want a more advanced assertion, that's a
> different use case, and would involve custom profile development. The only
> one we worked on was the delegation flow (that's not just ECP, it's more
> than that), but it hasn't really seen much uptake for many obvious reasons.

I am not sure about the implication/usage of a custom profile...

> >We checked what can be done and we found different possibilities:
> >- having a non-expiring/long-lived SAML ticket
> 
> That doesn't change the audience or add an appropriate subject
> confirmation, and those are the primary issues from a SAML "correctness"
> point of view. Whenever I say "correctness", I'm not saying you can't do
> it "incorrectly", just that once you violate one rule, there's not much
> concern about violating the rest (such as the time conditions).

Yes.

> (...)
> >What approach seems the more robust/straight forward?
> 
> That's a loaded question. One way of attacking it is to ask if you really
> want delegation. That's more secure, but much more complex, than
> forwarding/impersonation models.

The fact is that we have to use WS-Security and a SAML token to protect 
our services.

We would like to do this while being as standard-compliant as possible, 
but if he have no choice, if using delegation is too costly/complex or 
not adapted to our architecture, we are also thinking of either altering 
the SAML (we could update the AudienceRestriction, replace the signature 
from the idP by a signature from the Liferay SP/portal) or creating a 
ticket from scratch in the portal code, the portlet WS client would 
present it to the CXF Web Service which would validate it according it's 
policy (time validity, audience, known/authorized provenance..). But if 
we can do something cleaner it would make us happier/safer. (And the 
Liferay portal/SP and CFX Web Services are under our control but not all 
idP we plan to be integrated with.)

For what I understand/imagine, delegation, despite it seems to be the 
way we would like to go (and almost addressing our use case), might 
require too much work (or could even not be possible) to integrate witch 
our CFX Web Services and our externals iDP...

I am not sure how forwarding/impersonation could be achieved, could you 
please elaborate a bit on these models?

It looks like that we are moving from the quest of the best solution to 
the quest of the less bad solution...

> I would probably suggest you move any follow up to the dev list,
> unless it's a question specifically related to use of the delegation
> code, but discussing use cases is ok here.

Done.

> HTH,

It helps clarifying things, thanks! (But it also open new questions...)

> -- Scott

Best regards,
Baptiste

-- 
Baptiste Grenier           Maat-G Software architect/developer
http://www.maatg.com                   Mobile: +33 786 341 687
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4633 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20130114/a7a662fc/attachment.bin