Hi Stephen, On Monday 14 April 2008 21:57:52 Burke, S (Stephen) wrote:

Paul Millar [mailto:paul.millar@desy.de] said:

...

...

VOMS:/atlas/*:EXCEPT:/atlas/higgs

...

What you describe is an invalid FQAN.

In what sense? Obviously the entire string (/atlas/*:EXCEPT:/atlas/higgs) is not an FQAN

Yes, this is the first point: the complete string is not a valid FQAN. If "VOMS" URI schema means the schema local part is a FQAN, then the example you posted is invalid. That said, I can't find it stated anywhere that the VOMS URI schema *is* a FQAN, this is merely what I remember it being.

but if that were the format then you would parse it into two pieces first (I don't think : is valid in FQANs, although I could be wrong, and you could use some other separator).

Yes, but then you're expecting clients to adopt additional parsing semantics, specifically parse up to the first colon (yes, colon is an illegal character, as is *) and split the text into two parts and process the second based on the "EXCEPT:" token. If VOMS URI means FQAN, you cannot reasonably expect clients to do that. If VOMS URI schema *doesn't* mean this, then there's no problem.

If you mean that /atlas/* isn't a valid FQAN that's true in a strict sense,

Aye.

but it is valid according to the matching rules now being adopted in EGEE.

Sorry, I'm not sufficiently familiar with the "*" usage.

If your point is that you need to know which format is being used, the suggestion was to have two separate PolicyScheme types, one without DENY or equivalent and one with.

Yes, sounds good. If I were to suggest something it would be to extend the name-space (i.e., not use "VOMS" for the URI with the EXCEPT statement) and document the precise format for a "FQAN predicate" (or whatever these are called). URI is extensible, so adding a new schema should be relatively easy. Although, defining "FQAN predicates" schema probably isn't part of what GLUE should be up to. Just my 2c-worth. Cheers, Paul.

Hi Paul, please, have a look at section 18.3 of latest GLUE spec. There is an initial draft of how rules can be specified using a 'basic' policy scheme for GLUE: basic rule ::= DN_RULE | VO_RULE | VOMS_RULE | ‘ALL’ DN_RULE ::= ‘dn:’ DN_NAME VO_RULE ::= ‘vo:’ [a-zA-Z0-9-_\.]* VOMS_RULE ::= ‘voms:’ VOMS_FQAN (‘EXCEPT’ VOMS_FQAN)? we may want to use a different prefix than 'voms:' if this remindes to just FQAN.

Although, defining "FQAN predicates" schema probably isn't part of what GLUE should be up to.

we need to address this because it is an important aspect for the interoperability. At least, we want to provide a basic scheme. Cheers, Sergio

Maarten.Litmaath@cern.ch wrote:

Ciao Sergio,

...

please, have a look at section 18.3 of latest GLUE spec. There is an initial draft of how rules can be specified using a 'basic' policy scheme for GLUE:

basic rule ::= DN_RULE | VO_RULE | VOMS_RULE | ?ALL? DN_RULE ::= ?dn:? DN_NAME VO_RULE ::= ?vo:? [a-zA-Z0-9-_\.]* VOMS_RULE ::= ?voms:? VOMS_FQAN (?EXCEPT? VOMS_FQAN)?

How would one express that a VO "foo" has access except for the groups /foo/bar and /foo/xyz?

probably we need something like this: SEPARATOR ::= ':' VOMS_FQAN_LIST ::= (SEPARATOR VOMS_FQAN)* VOMS_RULE ::= 'voms' VOMS_FQAN_LIST (SEPARATOR 'EXCEPT' VOMS_FQAN_LIST)? which means in your example: voms:/foo:EXPECT:/foo/bar:/foo/xyv I don't know if you prefer this instead of separated rules for each group with optional DENY Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

The syntax of the FQAN is defined by the people who worry about the security model. We should not have to discuss this. In Glue we should just make the statement that the FQAN should be used and reference the relevant security specification where this is defined. Laurence

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. 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. I completely realize that we need to be pragmatic but just like over design we can also be too pragmatic.

The syntax of the FQAN itself is defined by the VOMS developers, but they don't consider how it should be published in GLUE, or in general how it should be used for matching. This is similar to the situation with access protocol names - in principle they should be defined by SRM, but in practice they aren't so we have to do it. Indeed the recent review of authorsiation in EGEE basically endorsed the GLUE model and will change both the WMS and LCMAPS to follow it!

Stephen

If no specification exists then we have to use the defacto standard which is the current usage. As this is a Nordugrid use case, they should just state what syntax they currently use. Laurence Burke, S (Stephen) wrote:

glue-wg-bounces@ogf.org

...

[mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field said: The aim of Glue within OGF is to try and bring some of the other specifications together and not define so much by ourselves.

That's fine where specifications exist, but if they don't and people nevertheless want to publish something we have to establish some kind of rules. The alternative is that we tell Nordugrid that they can't publish such things unless someone else decides the standard - is that acceptable? Or else Nordugrid publish things which aren't interoperable so e.g. we can't submit jobs from EGEE to them, as I believe you are trying to do. For that matter, the decisions by the EGEE authz working group don't represent any kind of standard, in practice they can only be standardised if we include them in Glue.

...

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.

This particular case is nothing to do with EGEE, the request comes from Nordugrid. However, if EGEE had decided to keep DENY tags I don't see that we would have any choice but to include it in Glue - the alternative would be that EGEE would have to abandon interoperability. Similarly we have agreed to include the EGEE wildcard matching rules in Glue - are you saying we should refuse to do that? If so it will not be possible for GLUE-compliant middleware to submit to EGEE.

...

We should just be able to published the ACLs in the FQAN format and that is it.

If it doesn't satisfy real use cases that can't be it.

...

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.

I don't think that's realistic. It's a major struggle to get people to adopt Glue at all - I would give only 50/50 odds that Glue 2 will in fact be adopted by LCG for example (we're still trying to get glue 1.3 features adopted). If we can't support significant use cases the chance drops to pretty much zero.

Stephen

I don't think there is a current usage, hence the discussion ...

We should try to avoid this kind of things as much as possible. We should not try to propose solutions for use cases we have no experience and put it directly into the spec. If this is important for Nordugrid (or EGEE), we should extent the schema and evaluate the solutions on our own infrastructures before proposing the solution to Glue. As this is a syntax on and attribute, it should only really affect the document rather than the schema implementation. Focusing on issues like this will distract and slow us down for the rest that we do have experience on. Laurence

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

If this syntax is required, it should be defined by the group that defines FQANs. There are many places in the architecture where such matchmaking takes place and the information system is just one of them. The problem within EGEE, as you stated was that the method of matchmaking in LCMAPS and the WMS was not consistent. I realize that some of us involved in Glue would also be involved in the other discussion but we need to separate these different roles. We should not define this syntax but reference where this syntax if defined. If this syntax has not been defined we need to state this and not make invent one. Laurence

Maarten.Litmaath@cern.ch [mailto:Maarten.Litmaath@cern.ch] said:

Has this syntax been discussed:

VOMS:/foo DENY:VOMS:/foo/abc DENY:VOMS:/foo/xyz

That was what Balazs was proposing in the meeting. My point was that it's quite hard to define that syntax in a generic way - for example, what if you say VO:/foo DENY:VOMS:/foo/abc does the DENY apply to a rule in a different scheme? Effectively if you go that way you have two different kinds of rules, deny-rules and allow-rules, and you have to process all the deny-rules first - and if a parser can't interpret a rule (e.g. it only knows about VO: rules) it can make a wrong decision (although GLUE isn't a Policy Enforcement Point so that doesn't violate security, it just makes things inefficient). Anyway, Balazs' use-case seemed to be basically the one above, i.e. "cutting out" some part of the space from an allow rule because it's easier than listing all groups explicitly. I was suggesting that you can do that in a simpler way that having a fully generic DENY syntax. (Incidentally, note that EGEE has explicitly said it won't use DENYs, because it makes things too complicated.) One final point, consider this (perhaps overcomplex) rule: allow /atlas/* except for the subgroup /atlas/higgs except that you still allow the subsubgroup /atlas/higgs/production except for the subsubsubgroup /atlas/higgs/production/test With the :except: scheme you could do that: VOMS:/atlas/*:EXCEPT:/atlas/higgs VOMS:/atlas/higgs/production:EXCEPT:/atlas/higgs/production/test With DENYs I don't think you could do it, DENY:VOMS:/atlas/higgs would override the second rule. Stephen

Maarten.Litmaath@cern.ch [mailto:Maarten.Litmaath@cern.ch] said:

How would one express that a VO "foo" has access except for the groups /foo/bar and /foo/xyz?

If you adopted this scheme you would have two rules: VOMS:/foo VOMS:/foo/*:EXCEPT:/foo/bar:EXCEPT:/foo/xyz Note that the EGEE matching rules specify that /foo only matches the top-level group (only the primary FQAN is considered), so you need both /foo and /foo/* to cover a whole VO. Stephen