Difference between revisions of "Proxyassertion"

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)