[Go-essp-tech] Improving on token-based authorization for filedownload

[philip.kershaw at stfc.ac.uk]

Hi Luca,

>	it is still not clear to me wether you guys are going to install
an  
> ESG Gateway or not... 

Yes we want to follow the work that you've been doing and see what
components we can benefit from using but this alongside our other
services.  We're in the middle of deploying a new set of services
including the equivalent of a Gateway, and a Data Node hosting PyDAP and
COWS OGC services.  These will form the core of our new production
services and input into the IS-ENES code stack.

> If not, there clearly will be some issues in  
> integrating the BADC data access architecture with the ESG Data Node.


Then we don't have interoperable security something that we've been
working hard at achieving all this time. :(

> Maybe it can all be resolved by proper use of Tomcat filters in front

> of the Data Node... Coming to you specific questions:
>
>On Dec 2, 2009, at 8:00 AM, <philip.kershaw at stfc.ac.uk>
<philip.kershaw at stfc.ac.uk 
> > wrote:
>
>> Hi Luca,
>>
>> Just wanted to check up on this: is there now a schedule for  
>> implementing a replacement for the token based authorization?  I'd  
>> like to raise a ticket for this on the GO-ESSP Trac so that we can  
>> keep a record.
>We don't have a timeline for this yet. Assuming we decide to do it, it

>is quite a big task, I'm not sure it can be done before the opening of

>the archive, considering everything else that needs to happen...

But we have to tackle this and make something work. :)  Is it a question
of not having the developer effort available?  

The virtue of the filter based approach is that you could imagine
configuring a Data Node layered with your token based filter and any
other filters that would deal with for example OpenID and/or SSL client
certificate based access.  The Data Node could then 'talk' a number of
different protocols for access.

My understanding was that the token based solution was a temporary one
and when I first heard about it, firstly I was surprised and secondly
you already had it in place.

We've spent a lot of time working on interoperable security and using a
standards based approach.  It's worked well: we've got OpenID for Single
Sign On and Attribute release interoperable with SAML / OpenID AX.
Looking back authorisation was not such a concern in terms of federating
access: each organisation could manage it's own authorisation
infrastructure provided it used a role based system and respected the
respective attribute assertions from the Attribute Service / OpenID AX
interfaces.

Once we have security bridging separate components the Gateway - Data
Node then there is another interface to consider and interoperable
authorisation becomes important especially at what we're looking at here
where these components cross organisations.  The token based interface
is something which we've never discussed how we can interoperate with.

>>
>> I have concerns that interoperability is going to break for us with  
>> you.  Thinking through some possible scenarios:
>>
>> 1) We will have a data node here with the ESG software stack so for  
>> example a TDS protected with the token based system.  If we don't  
>> have a Gateway with the token based functionality does this render  
>> the token system on our data node useless? - If there is no token  
>> issuing functionality in our Gateway then no one can get tokens to  
>> access our TDS? ... Or can you apply for a token at some other ESG  
>> Gateway and get access to the Data Node here? i.e. are tokens  
>> transferable between Gateways/Data Nodes?
>
>Currently, the ESG filter in front of the data node will reject  
>requests that do not contain a token. Tokens must be generated by the  
>gateway where the data was published, so there are not shareable among

>Gateways. 

This is a big limitation.  If I used a certificate as my token I could
conceivably present it to whichever Data Node I liked and it would be
accepted in the same way as I can use my OpenID wherever I like in the
federation.

>If you want to use the ESG Data Node but not the  
>authorization tokens issued by the gateway, you may need to replace  
>the current token filter with some other mechanism...
>
>>
>> 2) We'll also have our own PyDAP and COWS services as part of our  
>> Data Node.  They're protected with OpenID and the certificate based  
>> wget access I outlined at GO-ESSP.  Can you see problems with other  
>> ESG Gateways referencing these services?  If they just reference the

>> endpoints directly from a browser then I'm guessing it's OK: the  
>> OpenID sign in process would be initiated here when the given  
>> endpoint was accessed.
>
>Probably browser-based access will be ok, although I would need to  
>understand more about your system to be sure. Is  there a place where  
>your openid protection system is documented in excruciating detail ?  
>(well, maybe not excruciating but detailed enough ?). 

It's straightforward in the sense that you can approach a protected Data
Node with a certificate (could be obtained from MyProxy or some other
means).  If you don't present a certificate, it defaults to OpenID based
access.  Something which is already supported at the Gateway level.  The
certificate based method lends itself well to a wget script or other
programmatic access.  OpenID to browser based access.

>But I am afraid  
>that the wget scripts generated by the gateway will not work, since  
>they contain tokens...

It would be better if we could arrange a call - I know, between
everything else :)  Do you have a spec for the token based authorization
architecture?

Cheers,
Phil
-- 
Scanned by iCritical.