Proxyassertion - Revision history

KateHartmann: Protected "Proxyassertion": author request ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

2016-05-17T20:48:50Z

Protected "Proxyassertion": author request ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

Kaerez: fixed more line endings

2016-05-10T14:00:36Z

fixed more line endings

Kaerez: added q and a and fixed line endings

2016-05-10T13:59:02Z

added q and a and fixed line endings

Kaerez at 13:41, 10 May 2016

2016-05-10T13:41:24Z

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

2016-05-10T12:53:53Z

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

New page

== 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

'''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

@@ Line 78: / Line 78: @@
 A: You should (if possible)!
 Q: Shouldn't I use a client certificate (i.e. "Two way TLS") between the proxy and the system/s?
 A: If possible - then yes. Also make sure the system/s properly check the certificate (CA authority signing, valid from, valit to, revocation via OCSP or CRL)

← Older revision	Revision as of 20:48, 17 May 2016
(No difference)

@@ Line 4: / Line 4: @@
 '''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'''
 . All inbound traffic MUST go via the assertion proxy as the only entry point into the data center/systems using assertion data.
 . 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.
 . The proxy must be a bastian host, fully patched and updated at all times, fully hardened, must only be used for this purpose.
 . A WAF is suggested as an additional protection layer before the proxy.
 . Communications should be securely encrypted in motion.
 . All systems should be secure per the OWASP top 10 and other security publications and recommendations.
 '''General Mechanism - Unauthenticated User'''
 . User reach's proxy requesting a protected resource/any resource (depending on solution needs)
 . Proxy authenticates user in a secure manner (internally or using other system intended for that purpose)
 . Proxy creates a secure cookie on the users browser
 . Proxy removes ALL headers
 . Proxy injectes assertion headers (e.g. user, user role, user IP)
 . Proxy forwards to the target system
 . Target system parses assertion headers and implicitly trusts them, having verified source IP is from the proxy
 '''General Mechanism - Authenticated User'''
 . User reach's proxy requesting a protected resource/any resource (depending on solution needs)
 . Proxy parses received cookie in header
 . Proxy verifies cookie and session validity
 . Proxy removes ALL headers
 . Proxy injectes assertion headers (e.g. user, user role, user IP)
 . Proxy forwards to the target system
 . Target system parses assertion headers and implicitly trusts them, having verified source IP is from the proxy