Is there a handy cook book on how to set up certificate based authentication
on CDOT 8.x, specifically for use with the SDK APIs?

I'm looking at the help doc for Session Managemet APIs for Perl,
(in netapp-manageability-sdk-5.4P1/doc/WebHelp/index.htm), but
it doesn't explain the steps sufficiently for me.

Re:
> From: "Payne, Richard" <richard.payne@amd.com>
> Date: Wed, 18 Mar 2015 15:40:47 +0000
> Subject: RE: NetApp API authentication
> To: Edward Rolison <ed.rolison@gmail.com>, "toasters@teaparty.net"
>  <toasters@teaparty.net>
>
> 7mode or Cmode?
>
> For 7Mode I’ve used, hosts_equiv authentication (which arguably could be better/worse than username/password).
>
> For Cmode I’ve setup certificate based authentication.
>
> I make use of the Perl APIs, but started with them and never looked at just using LWP & XML Parser so I can’t comment on that part.
>
> --rdp
>
> From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Edward Rolison
> Sent: Wednesday, March 18, 2015 11:34 AM
> To: toasters@teaparty.net
> Subject: NetApp API authentication
>
> Having started to review some of our filer automation scripts, I'm starting to look in a bit more detail at the API.
>
> My first conclusion is - the perl SDK doesn't actually seem to do anything much - it seems to be a reimplementation of LWP and and XML Parser.
>
> Given I have LWP and XML::Twig installed, and am making API calls just fine, is there anything I'm missing here?
>
> Aside from that though - authentication types.
>
> I currently use ssh public-private key pairs, in a trusted account on a management station to enable 'doing stuff' with filers. It _looks_ like my only option with the API is to create a designated service account, and assign permissions... and then embed a username and password in a script somewhere.
> That just doesn't sit well with me - I like what ssh-agent will do in 'unlocking' key files, and I don't like embedding (potentially privileged) usernames and passwords ... anywhere.
>
> Does anyone have a better solution than a couple of designated API users (privileged and read only) with a file somewhere embedding their username and password?
>
> Does anyone have a better approach?

> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> http://www.teaparty.net/mailman/listinfo/toasters


--
Brian Parent
Information Technology Services Department
IT Infrastructure Operations Group
Computing Infrastructure Team
UC San Diego
(858) 534-6090
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters