Shibboleth Developers

["Scott Cantor" <>]

> We're looking into extending Shibboleth to provide the ability to pass
> delegated credentials from the IdP to an SP.

Some things you need to nail down:

- what kind(s) of credentials?
- what are the privacy requirements?
- what are the delegated client/server protocols and language/code
requirements?
- what does the SP know about what it will need to access and when does it
know it?
- what is the IdP's relationship with the various services and the
technology supplying the credentials?
- what kinds of security are needed between the delegate, the IdP, and the
back-end service?
- how do sessions play into it?

This is why it doesn't generally get very far. There's no single answer, and
no simple answer, and it takes a lot of new code and architectural work.
 
The one extant case that was implemented involves SAML-based delegation to
HTTP-based services using a bearer model adapted from Web SSO, which Peter
referenced. Pieces of that work are sometimes critical to any use of
delegation, but it really depends on the specifics.

> Specifically, we would like to be able to pass WS-Security assertions

If you mean SAML assertions, I would suggest that you consider avoiding
WS-Security and consider the model we proposed and implemented involving use
of assertions via POST to get a cookie, and not as per-message tokens.

> or Kerberos 5 tickets, so that the SP can then use those credentials
> to authenticte to another service.

Kerberos tickets are a fairly different issue.

> For example, if we use Shib to
> authenticate users to our web portal, the portal would be able to
> extract the credentials from the Shib SAML assertion, then use those
> credentials to authenticate to our mail server on behalf of the
> user.   (Our portal currently gets an IMAP K5 service ticket in this
> way via Pubcookie, and then authenticates to Cyrus using the user's
> IMAP service ticket.  This way, the portal does not have to have
> "superuser" credentials to the IMAP server.)

That's a common Kerberos use case, but it takes Kerberos expertise to figure
out how to do this, the same expertise that went into pubcookie and cosign
and others. So far we haven't had it.
 
> So, that said, we are looking at either passing multiple SAML
> assertions between the IdP and SP, or embedding the credentials into
> the existing SAML assertion (perhaps as a Base-64 encoded blob).

Passing multiple assertions has the generally fatal flaw that it assumes you
know what the delegate wants to access before it starts. This is only
sometimes true, but it can work when it is. It's merely an optimization of
the work we did. It still requires very carefully crafting assertions with
the proper extensions to express delegation semantics, and that at least has
been looked at.

Otherwise, there are proposals at OASIS for carrying Kerberos tickets, at
least, as SAML attributes, but I don't know how well those proposals fit any
particular use cases. I've been told there are missing pieces or issues with
them. And there are certainly open questions about the policy models needed
at the IdP and SP to properly constrain the system.
 
> Is it possible to pass multiple SAML assertions at once to an SP?

It's legal in the SSO profile to pass multiple assertions as long as they
have the same issuer and the same subject. One or more of them could be
delegated assertions, and could carry Audience information that identifies
them as intended for use at a different relying party.

> The SP code seems to indicate that multiple Shib assertions can be passed
> (grep for "Shib-Assertion-Count"), but I don't see any way to actually
> do this.

You need new IdP code, just like the delegation work we did required, and
the layering isn't very clean, there's a lot of duplication right now I
believe.

I would tell anybody asking the same thing. If you need Kerberos support, we
need dedicated help from the right experts to implement the kinds of things
pubcookie and cosign and other software does so that it gets done safely and
properly.

If you need SAML delegation support, OTOH, I would advise against doing
anything new until you look at, understand, and try out the work that's
already been done.

-- Scott