Shibboleth Developers

["Venkata Krishna Ravula" <>]

Hey Tom,

 

               from your reply and Scott reply this is what I figured. The Portal is the resource. It asks Shibboleth to authenticate a user. We assume here Shibboleth is already configured and hence the authentication takes place. ( Need not bother about this because it is all a matter of placing correct config files. right ?? ) The result for this authentication is "automatically" forwarded to the Portal. We can then make use of X.509 certificates and communicate with GT. Now here, the Portal authenticates to the GT and the GT simply provides a service.
 

Did I get it right ?

 

When I install Shibboleth, is there an inbuilt API or does it mean we need to design it ?

 

Also I would appreciate if you could let me know details about the person whom I need to contact for the CAS methodlogy.

 

I understand this is a Shibboleth group. Yet I would like to ask one simple question regarding the Globus Toolkit.

 

How can I make a Portal talk to Globus ? My search has been in vain so far. I would appreciate if you could throw some light upon it. Do I need My Proxy for this communication to occur or could I simple use the toolkit like JAVA COG as the glue between the Portla and the Globus ??

 

Thanks in advance.

 

Venkata

 

On 11/30/06, Tom Scavo <> wrote:

On 11/30/06, Venkata Krishna Ravula < > wrote:
>
>                In the first step, I meant to say the following :
>
>       SHAR gets the attributes as ARM from AA.

Oh, you're using old terminology, which is partly why communication
broke down.  The only terms in current use are:

Attribute Requester (previously SHAR)
Attribute Authority (AA)

The term "Resource Manager" isn't used much any more (although I know
what you mean).

Note that "Attribute Requester" and "Attribute Authority" will be used
less and less since Shib 2.0 defaults to attribute push.

> This is then forwarded by the
> SHAR to the resource manager for authorization of the resource. Instead, I
> was wondering whether it would be feasible to send these attributes to the
> portal instead.

The portal IS the resource.  It receives the attributes in the HTTP
header of the request.  It also receives the raw (unfiltered)
attribute assertion in the HTTP header.  This assertion is not
suitable for forwarding, however.

>        In point 4, I wanted to imply that the Portal is trusted by the GT (
> sorry about that typo).

Yes, we assume the portal is trusted by GT, so the portal can
authenticate to GT with an X.509 certificate.  Today, the portal's
identity is mapped to a "community account" at the resource, that is,
there is no access control based on individual users.  We're trying to
change this.

> Also however after your response, I began to think on new lines.  " Would it
> be feasible to allow SHAR to send attributes to the RM. Then the RM would
> make access control decisions.

This is exactly what happens, yes.  The portal makes an access control
decision (to the portal) based on the attributes received from the
Shib IdP.

> The decision would be forwarded to the Portal.

Again, the portal IS the resource, so there's nothing to forward.

> The Portal would then based on the decision would either contact the
> GT or display an appropriate error message. Once the Portla contacts the GT,
> it would immediately pull up the resource ( cause GT simple trusts the
> portal ).

Not quite.  Again, the portal authenticates to GT with an X.509
certificate.  If that certificate contains attributes about the user,
and GT is able to use those attributes for access control, the grid
resource is returned to the portal, which in turn responds to the
user.

Another approach might be to use the Community Authorization Service
(CAS).  In principle, the portal could query a CAS server and obtain
an authorization decision assertion, which is then bound to the X.509
credential.  Not sure if that's how CAS is used today, however.  (I
know who to ask if you're interested in this approach.)

Tom