This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
integration:start [2018/05/18 10:11] 10.144.24.34 |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== No-code integration ====== | ||
- | ===== Overview ===== | ||
- | ADUCID offers No—code integration as default authentication method. It is implemented a set of modules including Apache web server and ADUCID core components. As result, target application receives user login name in http header (e.g. REMOTE_USER). | ||
- | |||
- | {{: | ||
- | |||
- | ===== How it works ===== | ||
- | - User open web application | ||
- | - Apache resolves it 401 - unauthenticated | ||
- | - [[integration: | ||
- | - As soon as user authenticates page is reloaded and proxypass used to retrieve the back-end application for user | ||
- | - Or Apache has to handle 403 Unauthorized - see [[integration: | ||
- | |||
- | ===== REMOTE_USER or any other attribute ===== | ||
- | 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 | ||
- | |||
- | ===== Security headlines ===== | ||
- | Apache has to be accessible only via TLS (https) | ||
- | Back-end application has to be separated and accessible only from Apache (http, ajp, ...) | ||
- | 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 | ||
- | |||
- | |||
- | |||