Choose timezone
Your profile timezone:
Collaboration meeting
→
Europe/Zurich
Vidyo
Vidyo
# Argus Collaboration Meeting - 7/4/2017
[Agenda](https://indico.cern.ch/event/630503/)
## General News
EOSC-Hub proposal has been submitted: some efforts allocated for Argus maintenance, even though
it is very limited (3 PM over 3 years).
## CA LoA Implementation Status
Implementation of "proposal 3" almost done (98%)
* Followed the [described proposal](https://docs.google.com/document/d/1GTtOMo8W-sIX2FdU_reIDCZ5cIGtW1JdoHQmkbADcZw/edit#heading=h.twwt6t6pp9va)
* Implemented as a PIP that is run last in the PIP chain
* Standard PIPs in charge of validating the certificate and setting request attributes
based on user certificate and extensions are run first
* New PIP is extracting the authentication profile from the request and matching
it against the policy for the VO (based on VO-CA-AP): if they don't match, the attributes
are cleared. If it matches, an additional attribute is inserted describing the authentication
profile.
* Open question: do we need to add support for multiple VO-CA-AP files? Currently only
one is supported
* Will introduce complexity to define/implement what can override what
* Keep the current implementation for the time being: wait for a real use case not
addressed to revise the design
* Should the VO-CA-AP file presence be mandatory if the new PIP is configured or should
the default should be to implement the current behaviur in absence of the VO-CA-AP
file
* Default behaviour seems a good idea but hardcoding the default policy does not seem
a great idea and making it configurable requires restricting the config attribute
to safe values...
* Seems easier to require the file to be present and ship a default VO-CA-AP policy
implementing safe defaults in a different place. Site will have to define a configuration
attribute for the PIP telling the VO-CA-AP to use (e.g. the EGI file)
* With this last approach, an explicit step is necessary to enable the IOTA CA support:
cannot be done by mistake just because a package was installed
* If necessary, would make it easy to detect a non standard/broken configuration by
comparing the checksum of the used file with known checksums
General agreement that the "proposal 3" both provides an easy transition without any
risk of misconfiguration and a flexible approach to apply different restrictions to
different resources.
Support for the new configuration options already implemented in the Puppet module maintained
by INFN.
* May also add support in YAIM for EL6 as it is still an official configuration tool
in UMD3, even though it has never been released with 1.7
Status of Argus version deployed in production: is the version run by sites collected
somewhere?
* Only a few instances are in the BDII
* Peter will check if the security team has the information
Timeline for having the packages ready for early adopters: end of April
* Next UMD release: May. We may try to make it.
Archival of the 3 proposal documents : on gitHub, discuss the details
* Probably the easiest is to create a repository for internal development documentation
## GDB Presentation Preparation
See slides in https://docs.google.com/presentation/d/1pVdbk1iILaIqLqJZNWukGZBvEqeif2uYPOBEz7FmkPQ/edit#slide=id.g1d60e18808_2_38
## AOB
Next meeting: Friday, May 19, 2pm
There are minutes attached to this event.
Show them.
