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

[Cantor, Scott]

On 1/14/13 10:19 AM, "Baptiste Grenier" <bgrenier at maatg.fr> wrote:
>
>I am not sure about the implication/usage of a custom profile...

It means you're on your own, basically.

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

That doesn't dictate the security model and the actors involved in the
transaction and how they relate to each other. WSS is a message format,
and has no semantics. It isn't a complete solution or a direction you can
follow by itself. It's like defining an HTTP header that says "security
goes here" but it doesn't define what the meaning of anything in the
header is.

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

If you just gen up a token in the client, you have no security added. That
doesn't do anything useful. The point of an assertion is that it's issued
by somebody else that the relying party trusts, not generated by the
client, the portlet in this case.

There is no standard for anything you're doing, unfortunately.

Delegation is not a specific thing, it's a model of accessing services in
a way that communicates client and user identity in a multi-tier use case.
It requires security tools that can express that complexity. Impersonation
eliminates the client identity and the client impersonates the user.
That's how forwarded Kerberos tickets work. Then there's the third way,
how most systems work, with clients that authenticate in some fixed way
and then just tell the service who the user is. That's how web apps talk
to databases for example.

All of that can be done a dozen or more ways with different pieces and
parts. There's no standard.

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

Nothing you do here will work with an arbitrary IdP. Sorry, but that's the
reality.

If you scale back "arbitrary" to "Shibboleth", you could look at stuff we
did. If you scale it back to "Microsoft STS", then you probably have
WS-Trust things that would work. Some of that will sort of work with other
STS implementations and some of it won't. Most anything involving WS-*
will mean custom work.

I know of no specs that any non-Shibboleth SAML IdPs follow to do this
sort of stuff, with the exception of the old Liberty web services stuff,
which is what we based the delegation implementaton we did on.

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

The delegation condition spec has a discussion of some of the security
models in these sorts of systems.

https://wiki.oasis-open.org/security/SAML2DelegationCondition

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

I don't envy anybody trying to do web services and even playing at real
security.

-- Scott