Bill, we disagree on some points, let me elaborate..
-----Original Message-----
I disagree that replication services need to enforce common security levels for replicas. If I have read access to a file, I can copy it and set its access to whatever I want. If that is important data, it is assumed that since I have read access I will take care of it. A community may wish to impose consistent access rights across replicas, but that is a policy issue not something inherent in replication services.
Replicating access rights is in the interest of the job submission system: if a file is replicated to site A, the job submission system assumes that it has the same permissions as elsewhere. If the file at site A is not readable for the job, then it fails, because of the file permissions were not replicated along with the content. If you degrade security consistency to a VO policy, then why would any VO that needs this security consistency trust the Grid infrastructure with their data? Knowing that the infrastructure will not enforce consistent security semantics across sites means to many applications relying on secure data access (sometimes due to legal issues) that the whole infrastructure is unusable to them. Since sites have the last say and VO services are not part of the site security infrastructure, it is not possible to enforce security semantics through VO policies alone (at least this is one of the conclusios we came to in EGEE). This is a crucial point in the data architecture: Do we intend to offer a consistent grid-wide security to the applications or not? Where does VO policy start and Grid/site security stop? How do they interact? Our strong belief is that the infrastructure has to be able to offer strong security. It may be that some sites decide not to support it - but then the VOs who rely on strong security should be able to choose not to include that site in their list of supported resources.
As to the federated security model, I again dont think that is necessary, if I access n different sites, I have to do n authentication and authorization checks and if any one of them fails the access fails. This does imply some things about uniform identity, they all trust the same CAs, even that they are all using the same security mechanism. It would also be a major pain to debug access problems, particularly if the system is dynamically choosing the resource so you dont even know where are accessing things. I suppose it might be possible to query your rights across all the resources and present a federated access rights list that was the least common denominator.
i don't quite follow here.. the user always should know where and why an access was denied, and a site should always keep a log of access data (audit trails).
The idea of users not wanting anyone, including admins knowing what they have stored is a security concern. How do we know that they are not storing stolen top secret information or that they are actually running bomb design software. I dont subscribe to this, but I have heard this argument from security folks before.
Biomed applications want to protect their patient's privacy, as they are required to do BY LAW. therefore they need to be able to encrypt files on the storage. If one does not agree with this policy, then it should be advertised in the storage policy that such sensitive applications would not use the resource. There may be conflicting legislations, we have to be able to deal with it. That can olny be done by properly advertising the security semantics of the Grid Sites and VO services.. Peter & Akos
Bill
-- William E. Allcock Argonne National Laboratory Bldg 221, Office C-115A 9700 South Cass Ave Argonne, IL 60439-4844 Office Phone: +1-630-252-7573 Office Fax: +1-630-252-1997 Cell Phone: +1-630-854-2842