Shibboleth Developers

["Venkata Krishna Ravula" <>]

Dear Tom,

 

               In the first step, I meant to say the following :

 

      SHAR gets the attributes as ARM from AA. 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.

 

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

 

 So, hoping now that my question was clear, would this be a feasible approach ?

 

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. The decision would be forwarded to the Portal. 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 ).

 

Thanks

 

Appreciate all your time and efforts.

 

Venkata

 

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

On 11/30/06, Venkata Krishna Ravula < > wrote:
>
> 1. When the Resouce Manger makes an access control decison, the decision is
> then sent to the Portal along with the requested resource.

I'm not sure what you mean by "Resource Manager"?  Can you elaborate
on this step?

> 2. The portal on checking the attributes ( through some mechanism ),
> forwards it to the Globus Toolkit.

If you're talking about the attributes asserted by Shib to the portal,
it's probably not appropriate to simply forward them to a backend
service (such as GT).  Presumably these attributes were provided to
the portal for access control to the portal.  Moreover, the attribute
assertion obtained from Shib is most likely targeted at the portal
since it was issued subject to policy with respect to the portal.
Shib doesn't know anything about the backend service, it only knows
about the portal.

That said, there are situations where forwarding and/or repackaging of
attributes is appropriate.  I won't go into details here, however.

> 3. Now we have the Portal and the Globus Toolkit to talk to each other
> through some certificates inorder to validate the genuinity of the data
> (attributes) received.

Yes, the portal (like all Grid Clients) authenticates to GT with an
X.509 certificate.  This certificate may contain attributes.  For
example, VOMS uses X.509 attribute certificates to bind attributes.
GridShib, on the other hand, binds SAML assertions to X.509.  Either
way, the portal pushes attributes to GT by binding these attributes to
an X.509 certificate.

Although the portal could bind the attribute assertion obtained from
Shib to the certificate, this is probably not appropriate (as
mentioned above).  However, the portal may be authoritative for
certain attributes, say, VO membership attributes.  If the portal were
able to resolve these attributes, and then issue and bind SAML to an
X.509 certificate, it could use this certificate to authenticate to
GT.

> 4. Once the globus establishes, the genuine owner as the Portal, it then
> provides the resource.

I'm not sure what you mean by this.  "Owner" of what?

Hope this helps,
Tom