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"
(Secure method of using a single proxy entry point to pass assertion data for user authentication and authorization using the headers) |
KateHartmann (talk | contribs) m (Protected "Proxyassertion": author request ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 4: | Line 4: | ||
'''Brief''' | '''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 | 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''' | '''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. | 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. | 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''' | '''Requirements''' | ||
| + | |||
1. All inbound traffic MUST go via the assertion proxy as the only entry point into the data center/systems using assertion data. | 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. | 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. | 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. | 4. A WAF is suggested as an additional protection layer before the proxy. | ||
| + | |||
5. Communications should be securely encrypted in motion. | 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. | 6. All systems should be secure per the OWASP top 10 and other security publications and recommendations. | ||
'''General Mechanism - Unauthenticated User''' | '''General Mechanism - Unauthenticated User''' | ||
| + | |||
1. User reach's proxy requesting a protected resource/any resource (depending on solution needs) | 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) | 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 | 3. Proxy creates a secure cookie on the users browser | ||
| + | |||
4. Proxy removes ALL headers | 4. Proxy removes ALL headers | ||
| + | |||
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 the packet source IP is from the proxy | ||
'''General Mechanism - Authenticated User''' | '''General Mechanism - Authenticated User''' | ||
| + | |||
1. User reach's proxy requesting a protected resource/any resource (depending on solution needs) | 1. User reach's proxy requesting a protected resource/any resource (depending on solution needs) | ||
| + | |||
2. Proxy parses received cookie in header | 2. Proxy parses received cookie in header | ||
| + | |||
3. Proxy verifies cookie and session validity | 3. Proxy verifies cookie and session validity | ||
| + | |||
4. Proxy removes ALL headers | 4. Proxy removes ALL headers | ||
| + | |||
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 the packet source IP is from the proxy | ||
| + | |||
| + | '''Q&A''' | ||
| + | |||
| + | Q: If the firewall is misconfigured then the solution security is compromised, isn't it? | ||
| + | |||
| + | A: Yes. As such you should make sure this doesn't happen via process flow and/or additional firewall, WAF etc.. | ||
| + | |||
| + | |||
| + | Q: What if the firewall is breached? | ||
| + | |||
| + | A: Then you have bigger fish to fry, as they say, if you want you can add more firewalls from different providers. | ||
| + | |||
| + | |||
| + | Q: If a rogue network administrator gains access to the switch / performs an attack (e.g. ARP poisning) they can breach the solution security. | ||
| + | |||
| + | A: Indeed. As such network security needs to be secure. | ||
| + | |||
| + | |||
| + | Q: Why shouldn't I just use SAML? | ||
| + | |||
| + | 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) | ||
Latest revision as of 20:48, 17 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 the packet 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 the packet source IP is from the proxy
Q&A
Q: If the firewall is misconfigured then the solution security is compromised, isn't it?
A: Yes. As such you should make sure this doesn't happen via process flow and/or additional firewall, WAF etc..
Q: What if the firewall is breached?
A: Then you have bigger fish to fry, as they say, if you want you can add more firewalls from different providers.
Q: If a rogue network administrator gains access to the switch / performs an attack (e.g. ARP poisning) they can breach the solution security.
A: Indeed. As such network security needs to be secure.
Q: Why shouldn't I just use SAML?
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)
