cloudfoundry-community/cf-uaa-guard-service

[Alpha/experimental] UAA proxy as a service

UAA Auth Route Service

(Based on https://github.com/benlaplanche/cf-basic-auth-route-service)

The UAA Auth Route Service is currently experimental, and it should not be integrated with production services yet.

Using the new route services functionality available in Cloud Foundry, you can now bind applications to routing services. Traffic sent to your application is routed through the bound routing service before continuing onto your service.

This allows you to perform actions on the HTTP traffic, such as enforcing authentication, rate limiting or logging.

For more details see:

• Route Services Documentation

Getting Started

There are two components and thus steps to getting this up and running. The broker and the filtering proxy.

Before getting started you will need:

• Access to a cloud foundry deployment
• UAA client credentials

First, run in command line install.sh to install dependencies.

Uncomment and fill in the environment variables required as the sample in manifest.yml.sample and copy the manifest to manifest.yml.

Run cf push to deploy both apps.

Once the broker is deployed, you can register it:

cf create-service-broker \
    uaa-auth-broker \
    $GUARD_BROKER_USERNAME \
    $GUARD_BROKER_PASSWORD \
    https://uaa-guard-broker.my-paas.com \
    --space-scoped

Once you've created the service broker, you must enable-service-access in order to see it in the marketplace.

cf enable-service-access uaa-auth

You should now be able to see the service in the marketplace if you run cf marketplace

Protecting an application with UAA authentication

Now you have setup the supporting components, you can now protect your application with auth!

First create an instance of the service from the marketplace, here we are calling our instance authy

$cf create-service uaa-auth uaa-auth authy

Next, identify the application and its URL which you wish to protect. Here we have an application called hello with a URL of https://hello.my-paas.com

Then you need to bind the service instance you created called authy to the hello.my-paas.com route

⇒  cf bind-route-service my-paas.com authy --hostname hello

Binding may cause requests for route hello.my-paas.com to be altered by service instance authy. Do you want to proceed?> y
Binding route hello.my-paas.com to service instance authy in org org / space space as admin...
OK

You can validate the route for hello is now bound to the authy service instance

⇒  cf routes
Getting routes for org org / space space as admin ...

space          host                domain            port   path   type   apps                service
space          hello               my-paas.com                            hello               authy

All of that looks good, so the last step is to validate we can no longer view the hello application without providing credentials!

⇒  curl -k https://hello.my-paas.com
Unauthorized

and if you visit it you will be redirected to UAA.

Knowing who is logged in

This service will forward a header X-AUTH-USER with the email of the logged in user.

cf-uaa-guard-service's Issues

404 Not Found: Requested route ('guard.bosh-lite.com') does not exist.

hi thanks for your opensource, i successfully deploy upto binding authy to my personal app. my app rocketchat pushed using docker to cloud foundry with mongodb backend database. after binding authy i am getting this error. i attached application env in below txt file

curl chatxpert.bosh-lite.com
404 Not Found: Requested route ('guard.bosh-lite.com') does not exist.

http://chatxpert.bosh-lite.com/home

404 Not Found: Requested route ('guard.bosh-lite.com') does not exist.

app-env.txt

how we can login to my application after binding uaa-guard

hi thanks for your open source, i have successfully bind the guard service. After binding how can i login to my application

curl -k https://chatxpert.bosh-lite.com
Not Authorized

CF push failed

./broker.go:82: cannot use serviceBroker (type *GuardBroker) as type brokerapi.ServiceBroker in argument to brokerapi.New:
*GuardBroker does not implement brokerapi.ServiceBroker (wrong type for Bind method)
have Bind(string, string, brokerapi.BindDetails) (brokerapi.Binding, error)
want Bind(context.Context, string, string, brokerapi.BindDetails) (brokerapi.Binding, error)
Failed to compile droplet

Set oauth state

As @cnelson pointed out, we currently pass "state" as the state token instead of a long unguessable string, and we don't verify it on auth callback. We should do this here or possibly send a patch to goth to handle it there--see markbates/goth#136.

Could be another interesting issue to tackle with @jseppi.

Error while pushing to PCF

When I did cf push getting following error in pivotal cloud foundry.

OUT -----> Running: go install -v -tags cloudfoundry .
OUT vendor/github.com/pivotal-cf/brokerapi/service_broker.go:6:2: cannot find package "context" in any of.
OUT /tmp/tmp.oaTXote51f/.go/src/broker/vendor/context (vendor tree)
OUT /tmp/cache/go1.6.3/go/src/context (from $GOROOT)
OUT /tmp/tmp.oaTXote51f/.go/src/context (from $GOPATH)

UAA Auth Route Service uaa-proxy-session cookies may be replayed indefinitely

As the team that is the main author of this repository, our team noticed a problem with the way that this service uses cookies. We’re writing it down here to let you know if you use (or are interested in using) the service, including if you might be interested in fixing the issue sooner than we can get to it. (Ping: @ArthurHlt and @dhrapson as recent contributors outside our team.)

The UAA Auth Route Service will accept uaa-proxy-session cookies it has issued even after the user has logged out of their session with the application. uaa-proxy-session cookies are not invalidated by logging out, and do not have an internal time-to-live. A default maxAge may be set, but this is only enforced by the client. Consequently, a user may copy their own uaa-proxy-session cookie and reuse it indefinitely. This may be a vulnerability in environments where sessions are required to have a maximum lifetime after which the user is challenged to provide their primary credentials for re-authentication and re-authorization.

For example, if you save the 'uaa-proxy-session' cookie, log off, log back in again, and replace the new 'uaa-proxy-session' cookie with the old one, that works, which is unexpected behavior and can be a security vulnerability.

The uaa-proxy-session cookie is hashed with a Message Authentication Code (MAC) so it cannot modified or forged for another user without knowledge of the secret, server-side key.

--@commit-dkp, @brittag, and fellow 18F/cloud.gov teammates