[Go-essp-tech] MyProxy Clients for ESG
Jim Basney
jbasney at ncsa.uiuc.edu
Tue Oct 27 08:57:38 MDT 2009
Hi Phil,
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.
If you're doing a custom client, there are many MyProxy clients already
available:
http://grid.ncsa.illinois.edu/myproxy/devguide.html
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/
Regards,
Jim
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.
>>
More information about the GO-ESSP-TECH
mailing list