Date: Oct 23, 2007
Present:
VO Services: Gabriele Garzoglio, Ted Hesselroth, Igor Sfiligoi, Valery Sergeev
EGEE: Oscar Koeroo, Alberto Forti
Globus: Frank Siebenlist, Rachana Ananthakrishnan, Yuri Demchenko
* Summary:
- discussed the document on obligations common to the AuthZ Interoperability
Group.
Topics:
-- need to investigate some types of the obligation attributes (e.g. list of
integer)
-- no formal XACML way of declaring obligation dependencies (e.g. MultipleGIDs
makes sense only ig UIDGID or Username is specified)
-- do we need a PoolName obligation i.e. unresolved PoolAccount name? This is a
GPBox use case to be discussed at the security meeting at CERN
-- when using the AFS token obligation, the handler must reject it IF the
channel was not encrypted.
-- we may not need the PrivilegeMask obligation anymore; using ACL's instead.
- discussed PEP -> PDP communication. SAZ (site authorization service) needs
more attributes than the typical request for local id mapping.
Request context will use to pass attributes like DN, FQAN, CA, VO and
to pass PEP capabilities
- action items:
-- Rachana will send a correction to the XACML example of List of Integer.
-- Rachana will do tests with an Array of integers to see how this works in an
obligation.
-- Oscar will check if base-64 string is fine to represent an AFS token.
-- Yuri: example of XACML interfaces will be published to this list
-- Alberto: send what user attributes are encoded in the XACML for
authorization via GPBox
------------
* "Obligations Common to the AuthZ Interoperability Group" document.
Draft at
http://home.fnal.gov/~garzogli/privilege/AuthZInterop/tmp/AuthZInterop%20XACML%20Profile%20v0.4.doc
- Is the declaration for "list of integers" ok in the doc?
It should be a complex data type, unbounded. We can create it.
Rachana will send a correction to the XACML example.
She can do tests with an Array of integers to see how this works in an
obligation.
Do we need tools or a wrapper to deal with complex types ?
- How do we constraint the fact that an obligation needs another one?
In principle, we could do it at the level of the application or externally. We
are not aware of standard external methods e.g. in XACML.
We will enforce it in the implementation of the obligation handler.
- If it bad if the AFS token conveyed through the obligation is sniffed over the
network?
Yes. It must be securely transported.
The handler will use the "AFS token" obligation only when privacy and integrity
are enforced.
Oscar has access to the full environment from the handler, so he can check.
Oscar will check if base-64 string is fine for an AFS token.
- Username:
it will return the resolution of the pool account name.
GPBox may need an obligation to return the pool name e.g. PoolName. In GPBox the
PEP resolves the pool name to an account name. This will be discussed at the
security meeting at CERN.
PRIMA would not know how to deal with it.
- RootPath and HomePath:
Home path is relative to RootPath (it isn't a full path).
In general, you do not strictly need UIDGID, but our use case does.
- Priority:
The higher the integer the higher the priority.
Priority is related to the place in the data request queue.
- Privilege Mask.
May not use it because of the ACL in Chimera.
We may use this in 1 year.
----------
* Requirements for beta version of the library, including new
requirements from SAZ. This is the context:
- What requirements do we want the beta version of the library to satisfy?
I'd like to go over the original list and add / select requirements
http://cd-docdb.fnal.gov/cgi-bin/RetrieveFile?docid=2339&version=1&filename=AuthZInterop-Jul10-07.ppt
Valery: SAZ implements an authorization service using white/black-lists. The SAZ
client (PEP) receives yes/no from the SAZ server (PDP). The SAZ client is
stand-alone or integrated with a resource gateway. PEP can send a proxy in the
request (e.g. as a string) or PEP can parse the proxy and send only the relevant
attributes. We'd like to do the latter. SAZ server takes decision based on DN,
CA (issuer), VO, role.
SAZ does not issue any obligation. In the future, we might need to extend SAZ
server with time restrictions using e.g. an obligation with "Not before" and
"Not after" attributes.
Yuri: we are interested in time restrictions
Igor: From the PEP, we should pass all info that we know about the proxy. We can
pass attributes as a base-64 encoded string or attrib. by attrib. In the future
we might need attributes that are not relevant today e.g. level of delegations,
certificate chain, etc.
How is it done today?
Rachana: for the AuthZ framework in the GT context, PIP pulls off different
info and push it in the authz framework. In GT 4.0.x, the attributes are stored
in the authorization context. You need the right attribute id to extract the
info. Today, we only need DN and issuer. We have a special VOMS PIP that knows
how to parse VOMS attributes. The syntax is attributeid = value, where value
can be any java object. These attributes will be available in the message
context. In XACML we can do it in request context. With SAML, we could push only
a restricted number of attributes.
Frank: in GT, we could create a SAZ PIP that collects all the required
attributes from the certs. It will be part of the request context.
Igor: we'd like to have a PIP that can extract all attributes.
Frank: we have to standardize names and data types for each attributes.
All: we agree
Alberto: for GPBox, we put user attributes in the XACML . To generalize
this, we still need to agree on the attribute ids and data types. Today, our PEP
has DN and FQAN, in the .
Oscar: can you send a snippet of an example: we may be able to adopt it.
Alberto: yes
Frank: may require extension: SAZ may need more than GPBox.
GG: We agreed to use to communicate PEP and PDP capabilities. We
can use to communicate user attributes.
Oscar: when is Joe Bester coming back from paternity leave?
Frank: end of Oct.