Shibboleth Developers

["Tom Scavo" <>]

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