I've added a few more comments to http://proj.badc.rl.ac.uk/qesdi/wiki/ShoppingBasket about how a shopping basket system might work. A key thing is to put the user interface back into the system -- for QESDI we plan to have a web page on which users can select WMS entries to pass to the WMS client. This would be a "context client".
Going back to the catalogue: there should be an entry giving the WMS for smart clients, and, rather than anything pointing at the context server should hand over to the context client. The handover from the catalogue to the server is a restful URL, with no security or session id required. The context client then can then pass the information onto the context server with security clearance. This is then the security scenario we have already established an architecture for (user at browser accessing services through a browser). >From the catalogue perspective, the idea is that there will be one entry giving the WMS (for smart clients) and one entry for a handler (the context client) which can take a completely ignorant user gently through to a WMS client. Cheers, Martin > -----Original Message----- > From: Kershaw, Philip (STFC,RAL,SSTD) > Sent: 17 September 2009 15:26 > To: Lawrence, Bryan (STFC,RAL,SSTD); [email protected] > Cc: Pascoe, Stephen (STFC,RAL,SSTD); Donegan, Steve (STFC,RAL,SSTD); > Juckes, Martin (STFC,RAL,SSTD); Norton, Peter (Tessella,RAL,SSTD) > Subject: RE: [ndg-technical] NDG Context Service proposal > > Hi Bryan, > > > -----Original Message----- > > From: Bryan Lawrence [mailto:[email protected]] > > > > On Thursday 17 September 2009 11:31:46 Kershaw, Philip > > (STFC,RAL,SSTD) wrote: > > > > > If you can reference a session cookie from your AJAX call and route > > > traffic over SSL then it doesn't seem much worse than the existing > > > cookie based security we have in place. User confirmation for > > > cross-domain security interactions could annoy the user > > though: if the > > > eXist service was in a different domain the user would need to be > > > prompted for signin. The eXist service itself would need to be > > > fronted either by a proxy hosting the Python security middleware or > > > else a Java security interface in a servlet. > > > > This so seems like the classic use case for a proxy > > certificate. A priori we know it's going to be cross-domain. > > We know that users don't want to even think about it. The > > services need to negotiate their own access. > > The problem is getting a certificate that could be utilised in the > context of an AJAX call. From the browser client the session cookie is > the only available credential. You could perhaps bootstrap obtaining a > proxy cert by using the cookie to make a logon request to a local > MyProxy service running in the same domain. The MyProxy service would > need an altered interface to accept a cookie as authentication token. > > The certificate once obtained could be used to enable client > authentication to an eXist endpoint served over SSL. It would > eliminate the need for user interaction with the authentication to the > eXist service. It would be messy but doable. > > Cheers, > Phil > -- Scanned by iCritical. _______________________________________________ NDG-technical mailing list [email protected] http://lists.ncas.ac.uk/mailman/listinfo/ndg-technical
