[Go-essp-tech] MyProxy Clients for ESG
Frank Siebenlist
franks at mcs.anl.gov
Wed Oct 28 09:09:46 MDT 2009
Hi Phil -
If I understand it well, then your wget solution also requires
downloading custom scripts to make this work - downloading myproxy-
client seems equivalent - or maybe download and drive myproxy-client
with wget through the script if it's not on the box - not sure about
invoking the webstart app from commandline...
I remember discussing with Jim the option of a http(s) protocol for
myproxy to keep firewall admins happy - it's nice to have and would
allow a wget-like implementation, but didn't seem to solve the "no
need to download anything" - maybe Jim could comment.
(sorry for typos - taxi is hitting lots of potholes..)
Regards, Frank.
FrankS (from mobile)
On Oct 28, 2009, at 7:40, <philip.kershaw at stfc.ac.uk> wrote:
> Hi Frank,
>
>> Sorry, maybe I don't understand the requirements well, but does the
>> webstart myproxy-client application meet the requirement for not
>> having to pre-install any custom clients?
>
> Thanks for the links for JWS. Rachana had sent me a link to the
> Java MyProxyLogon program a while ago. It looks good and easy to use.
>
> In the case of this discussion I'm interested in non-browser based
> client access. I've been working on secured access to OPeNDAP and
> OGC based services for the BADC in the context of ESG. There are
> the existing OPeNDAP clients to think of and how security hooks
> might be added but also something like wget based access is
> important to us. - It's readily available for users and useful in
> the scenario for non-interactive client access e.g. a cron job.
>
> We've been developing a method to secure services for these types of
> client. The client when querying one of these services is
> redirected by some security middleware to an SSL endpoint to
> authenticate. MyProxy fits nicely with this because the user can
> obtain credentials via their usual username/password at their home
> institution and use these to authenticate via SSL client
> authentication. The wget call is straightforward but in order to
> make the MyProxy call the user must have a dedicated client. This
> can put users off. We have a Python MyProxy client which is easy to
> use and maybe the MyProxyLogon program can be called minus the GUI
> with a command line arguments ... or maybe it could even be called
> via JWS in a non-interactive mode?
>
> The idea I've been looking at was the possibility of fronting the
> MyProxy server with a HTTP interface so that wget could be used to
> make the MyProxy call too eliminating the need for a specialised
> client. I've developed a Python based web service interface to do
> this and it looks like the NVO have done something similar. The
> usual MyProxy logon call is invoked from the web application so the
> caveat is, is it acceptable to allow a private key to be generated
> on behalf of the client and return it back over the HTTPS connection
> back to the client.
>
> Cheers,
> Phil
>>
>> On Oct 27, 2009, at 9:14 AM, <philip.kershaw at stfc.ac.uk> wrote:
>>
>>> Hi Jim,
>>>
>>>> I'll just observe that if you do key generation on the
>> client-side,
>>>> then you lose your feature of working directly with wget,
>> rather than
>>>> requiring a custom client.
>>>
>>> I had in mind that you could still avoid a custom client by
>>> including an 'openssl req ...' call to generate the key and
>> request
>>> prior to the wget. It could be wrapped in a simple script. It
>>> could be attractive for Linux users where they have openssl
>> already
>>> installed but it looses its appeal over other dedicated clients if
>>> this is not the case.
>>>
>>>> Also, we have a MyProxy Apache module which you might be able to
>>>> re-purpose to fit your needs:
>>>>
>>>> http://grid.ncsa.illinois.edu/myproxy/apache/
>>>
>>> That looks a close fit to what I've been doing with the Python based
>>> server middleware. Following the above scheme I'd need to
>> alter it
>>> to be able to receive the certificate request and return
>> the signed
>>> certificate in the response.
>>>
>>> Thanks,
>>> Phil
>>>
>>>>
>>>> philip.kershaw at stfc.ac.uk wrote:
>>>>> Hi Rachana,
>>>>>
>>>>> Thanks for making some enquiries about this. I did post
>> a query to
>>>>> the myproxy-user list a few weeks ago but it didn't come through.
>>>>> There must be a problem with my registration.
>>>>>
>>>>> The NVO work does look along the similar lines but without
>>>> looking at
>>>>> in depth I'm not sure if it's intended as a web front end
>>>> to a MyProxy
>>>>> logon or also a dedicated web service interface. I was
>>>> thinking along
>>>>> the lines of the latter. I think having a HTTP based
>> interface for
>>>>> MyProxy would open a lot of options for clients.
>>>>>
>>>>> Jim made the point,
>>>>>>>>>> The main issue with his design is that it violates the
>>>>>> proscription
>>>>>>>>>> against generating private keys on behalf of subscribers and
>>>>>>>>>> sending them over the network. That's why the MyProxy and
>>>>>>>>>> GridShib CA protocols
>>>>>>>>>> generate keypairs on the client-side and send a certificate
>>>>>>>>>> request.
>>>>>
>>>>> I'm guessing that the NVO team decided that it's acceptable
>>>> to pass a
>>>>> private key in this way. The Identity Provider login service is
>>>>> deemed a trusted intermediary between the MyProxy server
>>>> and the web
>>>>> client.
>>>>>
>>>>> With the web application I've been working on it could
>>>> changed to avoid passing the private key. The interface
>> between the
>>>> client and web application could send a
>>>> certificate request as MyProxy logon does. Username and
>>>> password could still be passed via HTTP Basic Auth as I described
>>>> earlier. It would mean the private key would be generated at the
>>>> client without being handled by the web application or passed over
>>>> the interface:
>>>>>
>>>>> HTTPS
>>>> MyProxy protocol
>>>>> HTTP client ----------------------------------> Proxy Web
>>>> Application ------------------> MyProxy Server
>>>>> HTTP POST Certificate request +
>>>> MyProxy logon
>>>>> username/password (HTTP Basic Auth)
>>>>>
>>>>> One other thought would be to write a wrapper to embedd
>> MyProxy in
>>>>> Apache as a module. This would eliminate the need for an
>>>> intermediary
>>>>> web application but obviously there would be a little more
>>>> development
>>>>> work involved :)
>>>>>
>>>>> Cheers,
>>>>> Phil
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rachana Ananthakrishnan [mailto:ranantha at mcs.anl.gov]
>>>>>> Sent: 26 October 2009 14:34
>>>>>> To: Kershaw, Philip (STFC,RAL,SSTD)
>>>>>> Cc: go-essp-tech at ucar.edu
>>>>>> Subject: Re: [Go-essp-tech] MyProxy Clients for ESG
>>>>>>
>>>>>>
>>>>>> Hi Phil,
>>>>>>
>>>>>> Please see thread below, there seems to have been some
>> similar work
>>>>>> with NVO. Does this seem like the functionality you need?
>>>>>>
>>>>>> Rachana
>>>>>>
>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: Bill Baker
>>>>>>>> Date: October 22, 2009 11:35:24 AM CDT
>>>>>>>> To: Jim Basney
>>>>>>>> Cc: Rachana Ananthakrishnan <ranantha at mcs.anl.gov>
>>>>>>>> Subject: Re: MyProxy web login: ESG & NVO
>>>>>>>> Reply-To: Bill Baker <bbb at illinois.edu>
>>>>>>>>
>>>>>>>> Yes, the NVO has a "Save as ..." credential download page at
>>>>>>>> https://nvologin1.ncsa.uiuc.edu/protected/welcome
>>>>>>>> . To use it, you will need to create an SSO account,
>>>> which is a
>>>>>>>> simple email-based registration.
>>>>>>>>
>>>>>>>> The script that operates it is written in Perl, and it
>> leverages
>>>>>>>> the MyProxy-pubcookie integration. Ray and I wrote it.
>>>>>>>>
>>>>>>>> The code is at
>>>>>>>>
>>>>>> https://svn.ncsa.uiuc.edu/svn/nvo-security/pubcookie/portal/va
>>>>>> r_www/portal/perl/Portal/
>>>>>>>> -- see GetEEC.pm
>>>>>>>>
>>>>>>>> The PEM conversion code seems clumsy to me -- I was
>> serving PEM
>>>>>>>> credentials straight out of MyProxy, but our partners who
>>>>>> actually
>>>>>>>> use the PEM credentials were having trouble with the
>>>>>> encryption (or
>>>>>>>> something -- I don't remember exactly what the problem
>> was) and
>>>>>>>> suggested the approach that the script currently uses.
>>>>>>>>
>>>>>>>> Bill
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Jim Basney"
>>>>>>>> To: "Rachana Ananthakrishnan" <ranantha at mcs.anl.gov>,
>>>> "Bill Baker"
>>>>>>>> Sent: Thursday, October 22, 2009 10:13:14 AM GMT -06:00
>>>> US/Canada
>>>>>>>> Central
>>>>>>>> Subject: MyProxy web login: ESG & NVO
>>>>>>>>
>>>>>>>> Hi Bill,
>>>>>>>>
>>>>>>>> Rachana pointed out to me some work in ESG to put a
>> simple HTTPS
>>>>>>>> interface in front of myproxy-logon that retrieves a
>>>>>> certificate and
>>>>>>>> private key. It made me think of the NVO login design that
>>>>>> lets you
>>>>>>>> download your certificate and private key from the browser
>>>>>> (via "Save
>>>>>>>> Link As..." if I understand correctly).
>>>>>>>>
>>>>>>>> I see some documentation for the NVO SSO system at:
>>>>>>>> http://mywiki.ncsa.uiuc.edu/wiki/NVO_SSO
>>>>>>>>
>>>>>>>> Are there other details you could share with Rachana?
>>>> Maybe there's
>>>>>>>> an opportunity for some code sharing between ESG and NVO.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jim
>>>>>>>>
>>>>>>>> Rachana Ananthakrishnan wrote:
>>>>>>>>> Hi Jim,
>>>>>>>>>
>>>>>>>>> Thanks for the quick response.
>>>>>>>>>
>>>>>>>>> Good point about about the keys sent on the wire. I am
>>>> presuming
>>>>>>>>> that with SSL they deem it acceptable to push private key
>>>>>> information.
>>>>>>>>> Is the
>>>>>>>>> NVO work separate module that can be leveraged?
>>>>>>>>>
>>>>>>>>> Rachana
>>>>>>>>>
>>>>>>>>> On Oct 22, 2009, at 9:58 AM, Jim Basney wrote:
>>>>>>>>>
>>>>>>>>>> Hi Rachana,
>>>>>>>>>>
>>>>>>>>>> I wasn't aware of this work. The closest thing to it
>>>> I'm aware of
>>>>>>>>>> is the NVO portal login, that also delivers the user
>>>> certificate
>>>>>>>>>> and
>>>>>>>>>> private
>>>>>>>>>> key over HTTPS. Certainly it'd be very nice for Phil to
>>>>>> share his
>>>>>>>>>> work
>>>>>>>>>> with the MyProxy community.
>>>>>>>>>>
>>>>>>>>>> The main issue with his design is that it violates the
>>>>>> proscription
>>>>>>>>>> against generating private keys on behalf of subscribers and
>>>>>>>>>> sending them over the network. That's why the MyProxy and
>>>>>>>>>> GridShib CA protocols
>>>>>>>>>> generate keypairs on the client-side and send a certificate
>>>>>>>>>> request.
>>>>>>>>>>
>>>>>>>>>> -Jim
>>>>>> On Oct 22, 2009, at 8:52 AM, <philip.kershaw at stfc.ac.uk>
>>>>>> <philip.kershaw at stfc.ac.uk
>>>>>>> wrote:
>>>>>>
>>>>>>> Hi Rachana,
>>>>>>>
>>>>>>> I've literally just finished developing it hence my
>>>> question. - I
>>>>>>> don't want to take it further at this stage if there's
>> something
>>>>>>> else that will do the same thing.
>>>>>>>
>>>>>>> The application simply fronts a MyProxy logon call with a HTTPS
>>>>>>> interface. The client sends a HTTP GET call to a web
>>>>>> server hosting
>>>>>>> an application which fronts a MyProxy server
>> translating the HTTP
>>>>>>> request into a MyProxy logon call.
>>>>>>>
>>>>>>> HTTP client --<HTTP Basic Auth over HTTPS>--> Proxy
>>>> Application --
>>>>>>> <MyProxy logon>--> MyProxy server
>>>>>>>
>>>>>>> Username and password are passed in the HTTP header using
>>>>>> HTTP Basic
>>>>>>> Auth. The proxy application is configured to receives the
>>>>>> request
>>>>>>> and passes it on to a MyProxy service to perform the usual logon
>>>>>>> process. The application receives the response back
>>>> from MyProxy
>>>>>>> and passes certificate(s) and key back to the HTTP client
>>>> in plain/
>>>>>>> text format. As it's over SSL, HTTP client and server can
>>>>>>> authenticate each other.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Phil
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Rachana Ananthakrishnan [mailto:ranantha at mcs.anl.gov]
>>>>>>>> Sent: 21 October 2009 17:18
>>>>>>>> To: Kershaw, Philip (STFC,RAL,SSTD)
>>>>>>>> Cc: go-essp-tech at ucar.edu
>>>>>>>> Subject: Re: [Go-essp-tech] MyProxy Clients for ESG
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Phil,
>>>>>>>>
>>>>>>>> This sound interesting. Can you send out pointers to this work?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rachana
>>>>>>>>
>>>>>>>> On Oct 21, 2009, at 9:57 AM, <philip.kershaw at stfc.ac.uk>
>>>>>>>> <philip.kershaw at stfc.ac.uk
>>>>>>>>> wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Dean mentions a improved MyProxy client below. I'd be
>>>>>> interested to
>>>>>>>>> find out more about it.
>>>>>>>>>
>>>>>>>>> We had some discussion about the ease of use of MyProxy
>>>>>> clients at
>>>>>>>>> GO-ESSP. I've been looking at this and have developed an
>>>>>>>> add on to
>>>>>>>>> our interface here to enable MyProxy logon via a
>> https call. It
>>>>>>>>> would mean the logon step could be carried out with
>>>>>> something like
>>>>>>>>> wget without the need for a specialist client. Does
>> anyone else
>>>>>>>>> know of any similar work? Are you looking to add an specific
>>>>>>>>> utilities in the Gateway for MyProxy integration?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: go-essp-tech-bounces at ucar.edu
>>>>>>>>>> [mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Dean
>>>>>>>> N. Williams
>>>>>>>>>> Sent: 20 October 2009 14:41
>>>>>>>>>> To: Pascoe, Stephen (STFC,RAL,SSTD)
>>>>>>>>>> Cc: go-essp-tech at ucar.edu
>>>>>>>>>> Subject: Re: [Go-essp-tech] next telco: ESG data node
>>>>>>>> progress, 4pm
>>>>>>>>>> UT,20th October
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Stephen,
>>>>>>>>>>
>>>>>>>>>> Bob and Gavin will be on the call today, so these
>>>>>> questions will
>>>>>>>>>> be answered in great detail. Gavin, Eric, and Neill are
>>>>>> working to
>>>>>>>>>> include GridFTP and a new improved MyProxy client. Bob
>>>>>>>> will point you
>>>>>>>>>> to the publisher commands. Bob and Gavin will discuss the
>>>>>>>> testing of
>>>>>>>>>> the publication installation and process. Finally, we
>>>>>> will discuss
>>>>>>>>>> updated material on the DN development, deployment, and
>>>>>> publication
>>>>>>>>>> timelines.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Dean
>>>>>>>>>>
>>>>>>>>>> On Oct 20, 2009, at 6:21 AM,
>> <stephen.pascoe at stfc.ac.uk> wrote:
>>>>>>>>>>
>>>>>>>>>>> Some items I'd like to discuss at the telco. today:
>>>>>>>>>>>
>>>>>>>>>>> * datanode deployment update
>>>>>>>>>>> * Data publication timelines -- I can report on our
>> expected
>>>>>>>>>>> publication timeline of UKMO data.
>>>>>>>>>>> * Testing the publication process. How should testing
>>>>>>>> "esgpublish"
>>>>>>>>>>> work? Are the constraints on what metadata we give our
>>>>>>>>>> test datasets?
>>>>>>>>>>> How do we unpublish test datasets, including removal from
>>>>>>>>>> the gateway?
>>>>>>>>>>> * Documentation. Is there any documentation on the
>>>>>>>> esgcet command-
>>>>>>>>>>> line tools ($CDAT_HOME/bin/esg*)? If not lets we
>> start a wiki
>>>>>>>>>> page on it.
>>>>>>>>>>> * GridFTP -- I'm not clear how this is meant to be
>>>>>>>> configured on the
>>>>>>>>>>> node.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Stephen.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> Stephen Pascoe +44 (0)1235 445980
>>>>>>>>>>> British Atmospheric Data Centre
>>>>>>>>>>> Rutherford Appleton Laboratory
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: badc-nmwg-bounces at zonda.badc.rl.ac.uk
>>>>>>>>>>> [mailto:badc-nmwg-bounces at zonda.badc.rl.ac.uk] On
>>>>>> Behalf Of Bryan
>>>>>>>>>>> Lawrence
>>>>>>>>>>> Sent: 19 October 2009 14:55
>>>>>>>>>>> To: go-essp-tech at ucar.edu
>>>>>>>>>>> Subject: [badc-nmwg] [Go-essp-tech] next telco: ESG
>> data node
>>>>>>>>>>> progress,4pm UT, 20th October
>>>>>>>>>>>
>>>>>>>>>>> Hi Folks
>>>>>>>>>>>
>>>>>>>>>>> As announced, the next telco will be 4pm UT, 20th
>> of October.
>>>>>>>>>>>
>>>>>>>>>>> (Yes, that's 0300 in Canberra, 0900 in San Francisco,
>>>>>>>> 1000 Denver,
>>>>>>>>>>> 1200 in NYC, 1700 in the UK, 1800 in Europe, and the
>>>> time will
>>>>>>>>>> change for
>>>>>>>>>>> most of us the following week).
>>>>>>>>>>>
>>>>>>>>>>> The telco will be limited to one hour in duration.
>>>>>>>>>>>
>>>>>>>>>>> Telco number is US +1-925-424-8105 access code 305757#.
>>>>>>>>>>>
>>>>>>>>>>> Because of the antisocial hour in the Antipodes, we're
>>>>>>>> planning to
>>>>>>>>>>> record the meeting ... so that we don't get sued because
>>>>>>>>>> of potential
>>>>>>>>>>> damage from massive caffeine spikes ... if anyone has a
>>>>>>>>>> problem with
>>>>>>>>>>> that (the recording that is), please speak out asap.
>>>>>>>>>>>
>>>>>>>>>>> Topic of the day: progress on installing and configuring
>>>>>>>>>> the ESG data
>>>>>>>>>>> node. I think the actual agenda will be constructed in the
>>>>>>>>>> first five
>>>>>>>>>>> minutes of the call.
>>>>>>>>>>>
>>>>>>>>>>> Dean has produced the attached document which will
>>>>>>>> eventually appear
>>>>>>>>>>> on the CMIP5 site. Do feel free to provide constructive
>>>>>>>>>> criticism, so
>>>>>>>>>>> the
>>>>>>>>>>> document can be as useful as possible for those following
>>>>>>>>>> us down this
>>>>>>>>>>> road.
>>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>> Bryan
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Bryan Lawrence
>>>>>>>>>>> Director of Environmental Archival and Associated
>>>>>> Research (NCAS/
>>>>>>>>>>> British Atmospheric Data Centre and NCEO/NERC NEODC) STFC,
>>>>>>>>>> Rutherford Appleton
>>>>>>>>>>> Laboratory Phone +44 1235 445012; Fax ... 5848;
>>>>>>>>>>> Web: home.badc.rl.ac.uk/lawrence
>>>>>>>>>>> --
>>>>>>>>>>> Scanned by iCritical.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> GO-ESSP-TECH mailing list
>>>>>>>>>>> GO-ESSP-TECH at ucar.edu
>>>>>>>>>>> http://*mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> GO-ESSP-TECH mailing list
>>>>>>>>>> GO-ESSP-TECH at ucar.edu
>>>>>>>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Scanned by iCritical.
>>>>>>>>> _______________________________________________
>>>>>>>>> GO-ESSP-TECH mailing list
>>>>>>>>> GO-ESSP-TECH at ucar.edu
>>>>>>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>>>>>
>>>>>>> --
>>>>>>> Scanned by iCritical.
>>>>>>
>>>>
>>> --
>>> Scanned by iCritical.
>>> _______________________________________________
>>> GO-ESSP-TECH mailing list
>>> GO-ESSP-TECH at ucar.edu
>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>
>> ---
>> Frank Siebenlist - franks at mcs.anl.gov
>> The Globus Alliance | Argonne National Laboratory | University of
>> Chicago
>>
>>
> --
> Scanned by iCritical.
More information about the GO-ESSP-TECH
mailing list