Oxidized Integration with LibreNMS SSO Authentication

Help
1

Hello!

I’ve got LibreNMS deployed using SSO authentication via mod_auth_cas in Apache. That’s working just fine. I’d like to add Oxidized into the mix with its http source type, but it only seems to support authentication via the X-Auth-Token header. Is there a way to exempt API calls from the full SSO treatment?

For reference, validate.php output is below.

====================================
Component | Version
--------- | -------
LibreNMS  | 21.10.0-93-gf23c5c0e7
DB Schema | 2021_25_01_0129_isis_adjacencies_nullable (224)
PHP       | 7.3.29
Python    | 3.7.10
MySQL     | 5.7.12
RRDTool   | 1.4.8
SNMP      | NET-SNMP 5.7.2
====================================

[OK]    Composer Version: 2.1.11
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[OK]    Database schema correct
2

Ideally, you don’t use SSO at all with Oxidized and only use the LibreNMS UI to access Oxidized data.

3

Sorry, I see where my question wasn’t clear enough. Oxidized itself can’t access the LibreNMS API because its request to https://librenms.example.org/api/v0/oxidized isn’t SSO-authenticated.

Running oxidized from the command line shows the following output, revealing that it’s getting redirected to our CAS server to go through the authentication process:

$ oxidized -d
751: unexpected token at '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://cas.stage.example.org/cas/login?service=https%3a%2f%2flibrenms.stage.example.org%2fapi_v0.php%2foxidized">here</a>.</p>
</body></html>
'
/usr/share/ruby/json/common.rb:156:in `parse': 751: unexpected token at '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> (JSON::ParserError)
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://cas.stage.example.org/cas/login?service=https%3a%2f%2flibrenms.stage.example.org%2fapi_v0.php%2foxidized">here</a>.</p>
</body></html>
'
4

I’m surprised that the API doesn’t just accept the token. I wonder if there is some odd config or if this is the normal thing with SSO and API access.

Should be a solution for this, but I don’t know what it is. Hopefully someone has a suggestion.

If LibreNMS allowed fallback to SQL auth, then maybe you could use an SQL account for Oxidized. Currently, it does not.

5

I think we use SSO at work (been a long time since I was involved in LibreNMS) and we use the API extensively with no issues.

6

Any chance you could post a sanitized copy of your Apache config? I suspect that’s where my issue is, but I’m not certain. I’m assuming there’s some sort of <Location "/api"> alchemy that can be done to override the CAS Auth configuration that I have in <Location "/">, but I haven’t been able to get it right yet.

Current Apache site config:

<VirtualHost *:443>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript
    ServerAdmin [email protected]
    DocumentRoot /opt/librenms/html/
    ServerName librenms.stage.example.org
    ErrorLog logs/librenms-error_log
    CustomLog logs/librenms-access_log combined

    <Directory "/opt/librenms/html/">
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews
    </Directory>
    <IfModule setenvif_module>
        SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>

    CASValidateSAML On
    CASValidateURL https://cas.stage.example.org/cas/samlValidate
    CASDebug on
    LogLevel debug
    CASAttributePrefix CAS-

    <Location "/">
        CASScope /
        Authtype CAS
        CASAuthNHeader cas_uid
        require cas-attribute eduPersonEntitlement:https://librenms.example.org/admin
        require cas-attribute eduPersonEntitlement:https://librenms.example.org/readonly
    </Location>

    SSLEngine on
    SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
    SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php-fpm/librenms.sock|fcgi://librenms/"
    </FilesMatch>
7

Just to circle back in case anyone else runs into this, my eventual solution was to run a separate VirtualHost just on the loopback address that didn’t use the CAS authentication module. This allowed the API to query localhost without getting redirected to our IdP.

Doesn’t feel like the cleanest solution, but it’s working.

8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.