Locking down SCIM Bridge IP/Ports

vhale404
vhale404
Community Member
in SCIM Bridge

I've set up the 1Pass SCIM Bridge in AWS using ECS/Fargate. We use Okta for an IDP FTR. Right now inbound is wide open to all traffic on all ports. I'm hoping to trim this down to only Okta's IPs and the ports that are strictly needed. I tried to put it only to allow traffic on 80 and 443 to start, but when I checked logged into the bridge again to do a health check I started to get an incorrect bearer token error. Are there other ports this needs inbound traffic to or should it just work on 80 and 443? Or is that unrelated to the incorrect bearer token stuff.

Would it be a better approach to instead limit it to only inbound traffic from Okta's IPs?

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • 1P_Amanda
    1P_Amanda

    Hi @vhale404!

    Did you use the scim-examples/aws-ecsfargate-terraform example? If so, it's setup so that only connections from the load balancer are accepted. I would not recommend limiting to only Okta's IP addresses because they can change, but you're welcome to try if you would like.

    What did the SCIM Bridge logs show when you started to get the incorrect bearer token?

    Cheers!
    Amanda

  • vhale404
    vhale404
    Community Member

    I did use that example, yeah. Thanks, that helps explain it a lot.

    So what's strange is that it looks like it's starting a new log stream every 2 minutes or so, almost as if it's restarting the container. This is with the security group allowing traffic over 443/80 from anywhere.

    As soon as I open it wide open to all traffic from anywhere it works fine.

  • 1P_Amanda
    1P_Amanda

    Yup, that looks like it's restarting, you're correct. If you look at the logs it will likely say that it's restarting - often fargate will restart it after 2 minutes of failed health checks, so it could be working fine, but failing health checks due to the required port(s) not being accessible. The health checked checks the port 3002 - can you open that to the load balancer?

  • vhale404
    vhale404
    Community Member

    That looks like it fixed it! Thank you so much!

    One last thing we've been seeing happen is when Cloud Providers are blocked in our 1Passord console's firewall rules the bearer token doesn't get accepted. We have the IPs of the load balancer whitelisted in 1pass though which should let that specifically through. When I remove the block to cloud providers and enter the Bearer token it succeeds no problem though. After I enter the token I can then block cloud providers again and it works fine, with no failed health checks or errors in the logs.

    This seems like more of a bug than anything else though, but I figured it worth bringing up.

    These are the errors in the logs with Cloud Providers blocked:
    [LOG] [1.6.2] 2021/02/12 17:53:19 (ERROR) AuthWrap failed to check session, trying to generateNewSession: failed to touch session: session not initialized
    [LOG] [1.6.2] 2021/02/12 17:53:19 (INFO) session invalid, generating new session
    [LOG] [1.6.2] 2021/02/12 17:53:19 (ERROR) generateNewSession failed to PerformAuthWithSRPCredentials: Authentication: DB: 403: Blocked by an account firewall rule
    [LOG] [1.6.2] 2021/02/12 17:53:19 (ERROR) AuthWrap failed to generateNewSession: Authentication: DB: 403: Blocked by an account firewall rule

    Other than that minor quirk with the setup, we appear to be all set now though!

    TYSM

  • 1P_Amanda
    1P_Amanda

    Thank you for bringing this to our attention, I'll log a ticket.

    Cheers!
    Amanda

This discussion has been closed.