On November 30, 2011 11:13 , "J.Lance Wilkinson" <[email protected]> wrote:
> I'm beginning to suspect that my problem now is a scripting issue
> -- because when I MANUALLY execute the commands from my script, the
> same commands I originally cited in my post, and they coincide with
> your 4 steps precisely, I think, I DO get thru to the application on
> the POST -- enough to be refused BY THE REMOTE APPLICATION because of
> an *authorization error* -- so I know the CoSign *authentication* IS
> suceeding or I wouldn't be getting that far. The CoSign
> authentication
> fails when I execute them together in my script, however.
I'd need more information about the problem in order to help with why
the same commands are not working in your script but work when you run
them manually. A good place to start is by examining the HTTP request
headers and the HTTP response headers for each of the curl commands that
you run.
Regarding the bit about "same commands I originally cited", note that
your forth curl command in your first post from this morning had a wrong
URL: it was POSTing to the central weblogin server instead of your web
application server.
>> Again, I recommend using a different type of authentication for
>> scripts, such as client-side SSL certificates, if this is possible in
>> your case.
>
> I'm not familiar of a way to set up authentication/authorization in
> Apache HTTPD, which is running the NAGIOS GUI I'm trying to work with
> that is already COSIGN protected, such that APACHE would do the
> client-side SSL authentication. I suspect it would require that
> the NAGIOS GUI cgi script(s) effect the client-side SSL stuff, would
> it not? And I don't have the resources/permissions to change it;
> wouldn't really want those anyway as I don't want to un-standardize
> it...
You should not need to change the Nagios CGIs. Here's an example, done
entirely via Apache HTTP Server configuration directives:
CosignProtected on
CosignAllowPublicAccess on
SSLVerifyClient optional
SSLVerifyDepth 1
SSLCACertificateFile /path/to/your/ca/root/certificate.cert
SSLUserName SSL_CLIENT_S_DN_CN
In addition to the above, you may want a SSLRequire directive that
appropriate restricts the certificates accepted based on whether it was
verified, which CA signed it, which user the certificate is for -- this
depends on your requirements, see the examples in the Apache HTTP Server
documentation.
The SSLUserName directive, above, determines what REMOTE_USER gets set
to when a certificate is supplied. You will need to change the value
for this directive based on how your client certificates are generated,
which in turn depends both on your local practices as well as what your
Certification Authority is willing to sign.
If the Certification Authority that signs your client certificates uses
intermediate certificates, you'll need to include those in the
SSLCACertificateFile and increase the value of SSLVerifyDepth appropriately.
Note that the CosignAllowPublicAccess directive will only populate
REMOTE_USER if the user presents a valid cosign service cookie, which
won't happen if the request the user is making is the first request they
are making to the cosign protected service. For this reason, you should
turn on CosignAllowPublicAccess only for the CGI that needs to accept
POSTs from scripts, and keep it turned off for all other resources on
the server. If a user hits that CGI without hitting some other
cosign-protected resource on the server first, REMOTE_USER won't be
populated and the user will (hopefully) get an authorization denied
error from Nagios; the workaround is to have the user hit some other CGI
or resource on the server first and then try again.
Nagios should neither no nor care whether REMOTE_USER was set because
the user was authenticated via cosign or via a client-side certificate:
it should just retrieve the username from REMOTE_USER and then proceed
normally, without needing any modification or customization. Take this
with a grain of salt, however, since I've never set this up for Nagios,
personally.
--
Mark Montague
[email protected]
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Cosign-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cosign-discuss
