Bram Gosseye
Bram Gosseye

Reputation: 11

Apache2 - classification/authentication per location

I'm developing a client-server application with WebDAV functionality. Apache2 is used as webserver, a Windows Phone application as client. I'm working with classifications: TOPSECRET - SECRET - CONFIDENTIAL - PUBLIC.

TOPSECRET: SSL mutual authentication + password/username
SECRET: SSL mutual authentication
CONFIDENTIAL: password/username
PUBLIC: no authentication (but SSL is required)

So far, it's working with this configuration in Apache2: the user must choose at which level he wants to authenticate and he will be directed to the correct folder.

    #For webdav configuration

    Alias /public /home/bram/Desktop/webdav/public
    Alias /confidential /home/bram/Desktop/webdav/confidential
    Alias /secret /home/bram/Desktop/webdav/secret
    Alias /topsecret /home/bram/Desktop/webdav/topsecret

    <Location /public>
    #no authentication required
        DAV On
        Satisfy Any
        Allow from all
        SSLVerifyClient none
    </Location>

    <Location /confidential>
    #only username-password authentication
        DAV On
        Satisfy Any
        Allow from all
        SSLVerifyClient none
        AuthType Digest
        AuthName "DavCompany
        AuthUserFile /home/bram/Desktop/password/digest-password
        Require valid-user
    </Location>

    <Location /secret>
    #only strong/device authentication (mutual SSL)
        DAV On
        Satisfy Any
        Allow from all
        SSLVerifyClient require
        SSLVerifyDepth 3
    </Location>

    <Location /topsecret>
        #Device + username-password authentication
        DAV On
        Satisfy Any
        Allow from all
        AuthType Digest
        AuthName "DavTopsecret"
        AuthUserFile /home/bram/Desktop/password/digest-password
        Require valid-user
        SSLVerifyClient require
        SSLVerifyDepth 3
    </Location>

My problem: When authenticated in TOPSECRET, the user also has to see the folders SECRET, CONFIDENTIAL end PUBLIC. When authenticated in CONFIDENTIAL or SECRET, the user has to see the folder PUBLIC. I'm not familiar with Apache2.

Has anybody a suggestion to make this work?

Upvotes: 0

Views: 345

Answers (1)

benschumacher
benschumacher

Reputation: 162

This is a tough one. I'd have to experiment to find the answer, but I think you want to try to avoid mixing authorization mechanisms in Apache (you're using SSL's builtins, along with Apache's core mechanisms). You may, also, need this to be more hierarchical.

This perhaps isn't the complete answer, but it should be a starting point. Try setting your "base" permissions in the <VirtualHost> you're working with and vary the Locations within scope:

<VirtualHost *:443>
    # other VirtualHost configurations
    # ....

    SSLVerifyClient optional
    SSLVerifyDepth 3
    Require ssl
    Satisfy all

    <Location /confidential>
        AuthType digest
        AuthName "DavCompany"
        AuthUserFile /home/bram/Desktop/password/digest-password
        Require valid-user      
    </Location>

    <Location /secret>
        Require ssl-verify-client
    </Location>

    <Location /topsecret>
        AuthType Digest
        AuthName "DavTopsecret"
        AuthUserFile /home/bram/Desktop/password/digest-password
        Require ssl-verify-client
        Require valid-user
    </Location>

</VirtualHost>

I'm sure the above isn't perfect, but I think it is along the right lines for what you're trying to accomplish. I haven't run this through Apache, so it is possible there are mistakes above, but I believe it is roughly accurate.

The idea of what I've done above is to try to keep the overall authorization plan within the same scope. From there, the "tighter" scopes are applied for their specific locations. I do think there is a problem in that the user files are separate, and the AuthName are different for confidential and topsecret. I think, as it is, users with topsecret MAY NOT have access to confidential with their credentials if the AuthUserFile isn't the same.

Upvotes: 1

Related Questions