ADUCID 4.x

1. User opens a web application
2. Apache resolves it with code 401 - unauthenticated
3. ADUCID Binder page is diplayed - it is ADUCID authentication page with login button and QR code
4. As soon as user authenticates page is reloaded and proxypass used to retrieve the back-end application for user
5. Or Apache has to handle 403 Unauthorized - see Authorization in No-Code

In Apache configuration just require authentication:

require valid user

User ID is sent to application in header attribute - REMOTE_USER In ADUCID AIM it is called UDI As we use Apache you can rename it to anything else - some applications use x-forwarded-user or other user ID

Example how to send X-forwarded-user instead of REMOTE_USER:

RewriteEngine On	
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule .* - [E=RU:%1]
RequestHeader set X-Forwarded-User %{RU}e

• Apache has to be accessible only via TLS (https).
• Back-end application has to be separated and accessible only from Apache (http, ajp, …)
• Apache installed for ADUCID shouldn't be used for applications. User another instance of Apache instead.
• Headers from client are not transported to the back-end as ProxyPass is used (unless you configure Apache to do it)
• So if users sents REMOTE_USER to Apache, it is wiped out and target application won't see it

This picture describes internal components of No-Code integration solution.

• Applications tested with ADUCID No-Code integration yet
• Authorization in No-code
• ADUCID Binder