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