Shibboleth Developers

["Tom Scavo" <>]

[cross-posting to gridshib-user]

Yes, Venkata, your use case is similar to others.  For example,
nanoHUB is an example of such a grid portal:

https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/NanoHUB

Note that the nanoHUB portal is not shib-enabled, however.  Indeed,
most production grid portals are not shib-enabled, since SAML-based
authentication on the front end is mostly separate from X.509
authentication on the back end (as you've noted).  We (GridShib) are
working to preserve the authentication context across the portal, that
is, the grid service would like to make an access control decision
based on the authentication context (shib or not).

The grid service does indeed trust the portal to request a service on
behalf of the user.  Today, the primary mechanism is a "community
credential" possessed by the portal, which is mapped to a "community
account" at the grid service.  The portal creates a proxy certificate
based on its community credential, which it uses to authenticate to
the grid service.  This proxy certificate may contain extra
information (extensions) that allow the grid service to query a
Shibboleth IdP for attributes.  Alternatively, the proxy certificate
may contain SAML assertions with attributes.

If you have further questions, you might want to post to gridshib-user
directly.  My colleague Tim Freeman (and others) will be able to tell
you much more. ;-)

Cheers,
Tom

On 11/28/06, Venkata Krishna Ravula 
<>
 wrote:
> Hi Tom,
>
>              appreciate your response. Firstly, my apologies on being
> unclear about the issue. Let me explain the scenario in steps:
>
> Step 1: User goes onto the web-portal  to request a particular service
>
> Step 2: User is then authenticated  and authorized using Shibboleth ( Globus
> is not involved here )
>
> Step 3:  On positive credentials, the portal now communicates with the
> Globus ToolKit.(Shibboleth is not involved anymore hereafter)
>
> Step 4: Portal requests for a service from the Globus ToolKit.
>
> Step 5: Globus assumes that if the Portal requests a service then it simply
> is right in its asking. ( I mean the Globus simply trusts the
>            Portal) [ This is where I am unable to figure as to how to make
> this happen  and also if this a feasible implementation ]
>
> Step 6: Globus provides the service/ resource.
>
> I hope I broke down the problem into simpler terms. Incase of any confusion,
> yet do please let me know.
>
> Appreciate all your time and effort.
>
> Regards
>
> Venkata
>
>
>
> On 11/28/06, Tom Scavo 
> <>
>  wrote:
> > Hi Venkat,
> >
> > On 11/27/06, Venkata Krishna Ravula 
> <
>  > wrote:
> > >
> > > Now I guess the whole question is to make the portal once authenticated
> with
> > > proper credentials to be trusted by the Globus tool kit. This is where
> the
> > > entire scenario revolves. How to make the portal to be trusted by the
> GTK
> > > after authenticated by Shibboleth ? Any suggestions would be greatly
> > > appreciated.
> >
> > It's not exactly clear what you're after, so if you could elaborate a
> > bit on what you want to do once the user has authenticated to the
> > portal, that would help.
> >
> > As I mentioned earlier, there are grid portals in production today
> > that request grid services on behalf of the user.  The portal may or
> > may not be shib-enabled, that's mostly irrelevant.  The grid service
> > trusts the portal to make requests on behalf of the user.  The portal
> > possesses a "community credential" for this purpose.
> >
> > Cheers,
> > Tom
> >