[Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ

[Duane Merrill]

Yes, your certificate authority could sign ACs into PKCs.

This would be a reasonable strategy if, for example, your middleware
had statically-assigned identities (and statically-associated
attributes) and you wanted to call into resources operated by a
(idealized) middleware that looks for VOMS-style proxy-certs. (Because
the callee middleware knows how to process PC chains with embedded
ACs, it also knows how to process your vanilla PKCs with embedded
ACs.).

In this case, the callee services wouldbe advertised in EPRs as being
pgi-proxy-ac-tls compliant.

Duane


On 3/20/09, m.riedel at fz-juelich.de <m.riedel at fz-juelich.de> wrote:
> hi,
>
> can you not just use the full end-entity certs with extensions (i.e. put ACs
> there=?
>
> Take care,
> Morris
>
>
>
> --------------------------------------------------------------------------------
> Morris Riedel
> SW - Engineer
> Distributed Systems and Grid Computing Division
> Central Institute of Applied Mathematics
> Research Centre Juelich
> Wilhelm-Johnen-Str. 1
> D - 52425 Juelich
> Germany
>
> Email:  m.riedel at fz-juelich.de
> Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel
>
> Phone: +49 2461 61 - 3651
> Fax: +49 2461 61 - 6656
>
> Skype: MorrisRiedel
>
> 'We work to improve ourselves and the rest of mankind.'
>
> ----- Original Message -----
> From: Moreno Marzolla <moreno.marzolla at pd.infn.it>
> Date: Friday, March 20, 2009 3:55 pm
> Subject: Re: [Pgi-wg]
> Sec:	Agreement	on	attributetransportmechanismsforAttrAuthZ
>
>> m.riedel at fz-juelich.de wrote:
>> > Hi,
>> >
>> >> - This is the problem you mentioned which we experienced during
>> the
>> > OMII-EU project: BES clients were not executing the delegation
>> > operation, so the service did not have any delegated credentials
>> to use.
>> > We then implemented a horrible workaround in CREAM which was
>> fine for
>> > demonstration purposes, but unfortunately can not be applied for
>> any
>> > real use.
>> >
>> >
>> > ok, that's interesting - if you don't extract the proxy
>> obviously then from TLS level during AuthN steps - why is there
>> still a proxy support needed on the TLS level then?!
>>
>> I answer your question according to the understanding I just
>> gained from
>> our security experts, so bear with me :-)
>> The gLite middleware relies on VOMS extensions to associate roles
>> to
>> users according to the VO they belong to. If you use plain X509
>> certificates, of course you don't have any VO information there,
>> so it
>> is not possible for services to assign roles to the bearer of
>> those
>> certificates.
>> Suppose you want to submit a job to CREAM, and the job needs to
>> stage
>> external data to/from a service which DOES require VO extensions
>> in
>> order to perform authorization decisions. In this situation you
>> need at
>> least to delegate to CREAM a certificate with VOMS extensions (the
>> delegated certificate will be used by CREAM to access external
>> resources
>> on behalf of the user).
>> Of course, if you have an X509 certificate signed by a
>> "conventional"
>> certification authority, you cannot stick VOMS extensions inside
>> it. For
>> this reasons, when gLite users want to interact with CREAM
>> directly,
>> they first create a VOMS proxy certificate via the voms-proxy-init
>> command. Thus, using a proxy to interact with CREAM is only needed
>> to
>> have VOMS extensions inside the credential used to interact with
>> the
>> service.
>> If your job does not require to access any external service, OR if
>> that
>> external service does not rely on VOMS extensions, then you are
>> perfectly fine using plain X509 certificates only.
>>
>> Moreno.
>>
>> --
>> Moreno Marzolla
>> INFN Sezione di Padova,    via Marzolo 8,   35131 PADOVA,  Italy
>> EMail: moreno.marzolla at pd.infn.it         Phone: +39 049 8277103
>> WWW  : http://www.dsi.unive.it/~marzolla  Fax  : +39 049 8756233
>>
>>
>
>
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
>
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
> Dr. Sebastian M. Schmidt
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
>