RemoteUser and X509 client certificate

[Ian Bobbitt]

On 1/23/18 8:24 AM, Oluf Færø wrote:
>
> Hi,
>
>  
>
> I need to implement X509 client certificate authentication using an apache 2.4 as a reverse proxy and Shibboleth as
> the SAML IDP.
>
>  
>
> Currently Apache validates the certificate and successfully proxies the request to the Shibboleth IDP running in Jetty.
>
>  
>
> But I am in doubt if I should configure Shibboleth to use the RemoteUser authenticator or if I should go for one of
> the other authenticators.
>
RemoteUser is the easiest if you don't need access to anything in the certificate other than that component of the DN
you're putting in the header the flow is looking at. You can use the X509 login flow too, and therefor get access to any
part of the certificate's subject, but you would have to do a little work to reinject the certificate into a request
attribute for the flow to find.
>
>  
>
> The RemoteUser works and picks up the user name which is included in the header SSL_CLIENT_S_DN_UID from the apache
> proxy. But it does not make any check to validate if the username is valid.
>
The RemoteUser login flow assumes the users given to it have been vetted outside the IdP and are valid. It has to. The
username, and the fact that it got to the flow, are the only pieces of information it has.
>
>  
>
> The user client certificate is valid, but to resolve the attributes successfully it is also necessary that the user
> name is exists, right? I would prefer at configuration where the attribute resolution queries a database for the
> attributes based on the user name.
>
>  
>
Sure, querying a relational database is well documented.
<https://wiki.shibboleth.net/confluence/display/IDP30/RelationalDatabaseConnector>. There are (commented out) examples
of almost exactly what you need in the `attribute-resolver-full.xml` config file that came with the IdP installation.
>
> Can you please provide any guides on how this should be implemented
>
>
If you need more flexibility than you can get from the login flows and attribute resolvers, you can script your logic in
the MFA flow <https://wiki.shibboleth.net/confluence/display/IDP30/MultiFactorAuthnConfiguration> or a context check
flow <https://wiki.shibboleth.net/confluence/display/IDP30/ContextCheckInterceptConfiguration>. From there you can, for
example, check that an attribute has an expected value (e.g. activeUser = true) and otherwise deny the login (e.g.
redirect to a page explaining why the user is unable to log in).

That said, backing up a few levels... it's worrying that you have valid certificates that don't map to valid users.
Revoking no-longer-valid certificates, and checking those revocations are important parts of a proper certificate trust
model. Apache can check a CRL <https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcarevocationcheck> or OCSP
responder <https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslocspenable> to determine if a client certificate is
revoked.

-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4090 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20180123/c7675400/attachment.p7s>