[gridshib-user] Integrating Shib for web service application, any suggestion?

[Tom Scavo]

Hi Weizhong,

On Mon, Sep 29, 2008 at 6:10 AM, wz qiang <weizhongqiang at gmail.com> wrote:
>
> Firstly, we have implemented a Web Service container, and some web services
> (basically for grid application, like grid job manager). So basically the
> idea about integrating Shib is trying to utilizing the Shib IdP to get the
> Authentication result and Attributes for protecting the web services.
> There are client (which will access service) and service out web service
> implementation. The idea about intergrating Shib IdP is the same as the use
> case in Shibboleth, except we are protecting normal web service instead of
> web application in Shib SP

If you examine the SAML Web Browser SSO profile closely, you'll see
that it relies on one or more HTTP bindings (POST, Redirect, Artifact)
and that it assumes the client has all the capabilities of a standard,
off-the-shelf web browser (including redirects and cookies).  So if
you want to mimic Web Browser SSO, you need a client that supports
standard, web browser functionality.  What you end up with is a client
that *is* a web browser, for all intents and purposes.

> and we are using some specific code in the
> client to interact with service instead of the Web page in Shibboleth
> client.
> 1, Client access service. A security handler in service will interact with
> the security handler in client to do something like: Where are you from?

IdP discovery remains an unsolved problem.  The best solutions we have
today require a complicated series of redirects, cookies, and
javascript.  Either your client tries to mimic what we have today (in
which case, it must support redirects, cookies, and javascript) or it
supplies a pointer to the IdP up front, so that the SP doesn't have to
discover the user's IdP.

> Composing AuthnRequest, and then return the AuthnRequest to client.
> 2, Client authencate with Shib IdP by using whatever mechanism.

What mechanism?  Web Browser SSO permits the IdP to interact with the
client to gather credentials.  In your flow, is it permissible for the
IdP to interact with the client?  If so, you need to support
redirects, cookies, and perhaps some HTTP authentication mechanisms
(such as basic auth).  Again, you'll end up implementing a browser.

> 3, Client get the AuthnRequest and POST it to Shib IdP by http protocol, and
> get back b64 encoded Saml response which included the encrypted
> Authentication assertion from Shib IdP.
> 4, Client (the above security handler in client side) POST the above saml
> response to service; then the above security handler in service side will
> decode, verify this saml response, and decrypt the saml assertion and saml
> NameID in this saml assertion.

Yes, that's a good description of SAML Web Browser SSO, but when you
start substituting nonbrowser clients for ordinary browsers and Grid
SPs for ordinary SPs, the above scenario collapses and you're left
scratching your head.

> 5,The security handler in service side use this NameID to compose a saml
> Attribute Query, and send it directly to Shib IdP, and finally get back the
> attributes which will be used for authorization.

I'd recommend avoiding attribute query if you can, by pushing
attributes up front.  The flow (and the implementation) will be much
simpler as a result.

> So the basic idea is to mimic the client-agent and Shib SP in the typical
> Shibboleth scenario, but keep the Shib IdP. The benifit it that we can
> utilize the widely-deployed Shib IdP for protecting web/grid service.

Well, my own personal assessment of the above approach is: it simply
won't work.  Our project has spent the last four years trying to solve
this very problem, with little success.  Maybe you can do better, I
don't know :-)

If you go read the roadmap for Shibboleth 2.2, you'll see the plan is
to support X.509 authentication at the IdP and the ECP profile.  Also,
the beginnings of an STS has been committed to OpenSAML 2.0.  If you
read between the lines of the roadmap, you'll see that a possible grid
flow is emerging from all that.  It'll be interesting to see how that
all shakes out.

Tom