NSA A/A [Was: SSO authentication: a new approach]

Hi,

You don't know me, but I've just been told I'm responsible for security in the NOAO Science Archive (NSA). I've stumbled across this thread while casting aroud trying to understand a little more what other people are doing wrt security and the VO (Ray - I think Arno will be contacting you soon, or has already done so, and I guess we will be talking in more detail).

So I'm trying to work out how the NSA would fit into the scheme of things.  I think it would be great for us to have an external authentication service, which manages/verrifies identities, but I think we would want to keep control of authorization (because access to particular data will be a function of both the user's identity and the data's provenance - provenance being a complex fuction of the metadata within the archive).

At first glance, that seems clean enough. But I can see at least two problems, which I think others have also discussed here.

1 - It's not always easy to separate authentication and authorization. In a typical ACL scenario you need to search through relationships between subjects and permissions (for example, the user may not have the appropriate permission, but is a member of a group that does). In such cases, who is responsible for managing groups? It seems that naturally this is a job for the authentication service, but that gives me an efficiency headache if I want to do local authorization.

2 - How does this fit with the whole trust model? This affects the NSA in at least two ways. 2a: We need to start worrying about who is doing the request (ie implementing whatever trust model is decided on) 2b: We might need to start worrying about generating requests ourselves.

On the last point, what are people's opinions on the internal architecture of large(?) web services? Do issues like 2b mean that we should have message security internally, or is it more practical to handle authentication at the gateway and use whatever internal architecture we want (typically transport or network security), since we trust our own code, do our own authorization, and in general aren't worried about third party support?

Sorry if this seems rambling or just plain stupid in parts (and I guess perhaps the last question is not 100% relevant to this list). I'm still trying to get my head round the issues involved...

Thanks,
Andrew

Ray Plante said:
> Hopefully, I've exhausted this thread. ;-)
>
> cheers,
> Ray
>
>

-- 
` __ _ __ ___  ___| |_____   work web site: http://www.ctio.noao.edu/~andrew
 / _` / _/ _ \/ _ \ / / -_)  personal web site: http://www.acooke.org/andrew
 \__,_\__\___/\___/_\_\___|  list: http://www.acooke.org/andrew/compute.html