This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Proxyassertion"

From OWASP
Jump to: navigation, search
(Secure method of using a single proxy entry point to pass assertion data for user authentication and authorization using the headers)
 
Line 25: Line 25:
 
5. Proxy injectes assertion headers (e.g. user, user role, user IP)
 
5. Proxy injectes assertion headers (e.g. user, user role, user IP)
 
6. Proxy forwards to the target system
 
6. Proxy forwards to the target system
7. Target system parses assertion headers and implicitly trusts them
+
7. Target system parses assertion headers and implicitly trusts them, having verified source IP is from the proxy
  
 
'''General Mechanism - Authenticated User'''
 
'''General Mechanism - Authenticated User'''
Line 34: Line 34:
 
5. Proxy injectes assertion headers (e.g. user, user role, user IP)
 
5. Proxy injectes assertion headers (e.g. user, user role, user IP)
 
6. Proxy forwards to the target system
 
6. Proxy forwards to the target system
7. Target system parses assertion headers and implicitly trusts them
+
7. Target system parses assertion headers and implicitly trusts them, having verified source IP is from the proxy

Revision as of 13:41, 10 May 2016

Proxy based assertion

Brief Secure method of using a single proxy entry point to pass assertion data for user authentication and authorization using the headers to other systems

Purpose Allow internal systems to receive assertion details (e.g. user, role, customer ID) without the need to decrypt/verify a digital signature/contact a different system to verify a token. This method is useful for legacy systems, mixed environments (old and new) or areas where changes to applications/web applications are not possible or expensive.

Requirements 1. All inbound traffic MUST go via the assertion proxy as the only entry point into the data center/systems using assertion data. 2. Access MUST be protected by a firewall to prevent ANY access to the systems not via the proxy and as such direct access of any entity should not be allowed if bypassing the assertion proxy. 3. The proxy must be a bastian host, fully patched and updated at all times, fully hardened, must only be used for this purpose. 4. A WAF is suggested as an additional protection layer before the proxy. 5. Communications should be securely encrypted in motion. 6. All systems should be secure per the OWASP top 10 and other security publications and recommendations.

General Mechanism - Unauthenticated User 1. User reach's proxy requesting a protected resource/any resource (depending on solution needs) 2. Proxy authenticates user in a secure manner (internally or using other system intended for that purpose) 3. Proxy creates a secure cookie on the users browser 4. Proxy removes ALL headers 5. Proxy injectes assertion headers (e.g. user, user role, user IP) 6. Proxy forwards to the target system 7. Target system parses assertion headers and implicitly trusts them, having verified source IP is from the proxy

General Mechanism - Authenticated User 1. User reach's proxy requesting a protected resource/any resource (depending on solution needs) 2. Proxy parses received cookie in header 3. Proxy verifies cookie and session validity 4. Proxy removes ALL headers 5. Proxy injectes assertion headers (e.g. user, user role, user IP) 6. Proxy forwards to the target system 7. Target system parses assertion headers and implicitly trusts them, having verified source IP is from the proxy