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

[Cantor, Scott]

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.

>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).

>ECP [1][2] seems to be the preferable/standard way to go, but I have
>trouble understanding how to "ideally" glue all the pieces together in
>such a scenario/architecture. If I understand correctly, with ECP the
>CXF Web Services would have to act like a SP and interact with the IdP
>instead of using WS Security.

We try and refer to it as the "delegation profile" rather than just ECP,
to avoid confusion.

But yes, you're correct. I felt WSS was essentially a dead end, and in the
prototype we built, we did not choose to try and support message-level
security. We designed the delegation flow to be session based, like a
typical browser/server app is. It is, today, normally limited to bearer
tokens, but the framework can accommodate confirmation by keys in the
future if it were to stay around.

But the main goal was that I wanted to be able to protect web services
with a vanilla Shibboleth SP. I don't believe in building authentication
into code running on a web server. Others do, and that is the primary
differentiator between Shibboleth (the SP) and other approaches. I won't
try and convince anybody, I just know that my model has benefits and it's
been a consistent approach that I will probably always maintain. One of
SAML's fatal flaws is that there just isn't enough good code for doing it
the other way, particularly once you get into more advanced cases like
yours.

> CXF is also providing a tomcat plugin for
>Relying Party integration [3] with their Fediz federation [4].
>We also plan to support IdPs from external providers and I fear that ECP
>might not be supported...

Even if ECP were, delegation is not just ECP. It's layered on top, and
nothing else supports it, I would imagine.

>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.

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.

HTH,
-- Scott