[glue-wg] DENY rules

[Sergio Andreozzi]

Laurence Field wrote:
> The problem with an information model is that we can end up describing 
> everything.  The aim of Glue within OGF is to try and bring some of 
> the other specifications together and not define so much by 
> ourselves.  For example, JSDL should describe the job and Glue should 
> reflect this so that the job can be matched. The group defining JSDL 
> should worry about the matchmaking should be worked out jointly 
> between the JSDL group and Glue, but JSDL should be the definition 
> which Glue reflects and likewise for the Authorization.
>
> We need to narrow our focus or we will end up "boiling the ocean" 
> which has happened to many other Groups and the definition will take 
> forever.
>
> From what I can see on the use of DENY tags within EGEE, this is a big 
> hack to work around a implementation problem in the glite middleware 
> and as such should not dictate what is done in Glue.  We should just 
> be able to published the ACLs in the FQAN format and that is it.
>
> The reason for the DENY tags is the inconsistency with the simple 
> matchmaking done by the WMS and the mapping of VOMS FQANs in a CE.
that's not completely true. The WMS was also extended to support the 
DENY option (it is just the matter of defining a new matching operator).
The problem was that the LCMAPS component performed decision using a 
different logic than WMS (assuming order between rules). This should be 
solved in EGEE-3 as they have defined a number of recommendations which 
avoid the need for assuming ordering.

We can leverage these recommendations and propose a basic syntax for 
policy rules. This is an important interoperability aspect and we have 
experience to do this, more than in GLUE 1.x.

> If publishing only the FQANs does not work, it is not necessarily an 
> information model problem but architectural issue that needs to be 
> fixed and should be pushed back to those dealing the Authentication 
> and Authorization. We need to take a more minimalistic approach do the 
> schema definition and not try to fix other peoples problems.
it could work, but it is not efficient.

Consider the Balazs use case:

ATLAS has 100 groups. You want to state that 99 groups are authorized, 
but not /atlas/production/students.

With just FQAN you have to list 99 groups, this is inefficient.
The other way is to say

/atlas/*:EXCEPT:/atlas/production/student

or

ALLOW: fqan:/atlas/*
DENY: fqan:/atlas/production/student

this is a simple set of rules (just allow/deny) which should be easy to 
map to underlyng middlewares.

Cheers, Sergio