The cloud controller logs have "Invalid bearer token:
#<CF::UAA::InvalidSignature: Signature verification failed>" and the 401
invalid auth message.

On Fri, Sep 4, 2015 at 6:14 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Ok, I set those 2 properties to http://localhost:8080 and it looks
identical; same error, same endpoints requested.
Could something be wrong with the cloud controller config?

On Fri, Sep 4, 2015 at 5:58 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login

API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"
http://support.local.example.com","version":2,"description":"CF v2
test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API
endpoints are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now
the uaac commands from above work and I can run 'uaac token owner
get'. I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become
a bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for
them? I'm going through at the moment and trying to make mine resemble the
config here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com

wrote:

I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your
trace returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we
can fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <
kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override
the url it hosts the endpoints at?

Ok, I set those 2 properties to http://localhost:8080 and it looks
identical; same error, same endpoints requested.
Could something be wrong with the cloud controller config?

On Fri, Sep 4, 2015 at 5:58 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login

API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"
http://support.local.example.com","version":2,"description":"CF v2 test
environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now
the uaac commands from above work and I can run 'uaac token owner
get'. I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become
a bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for
them? I'm going through at the moment and trying to make mine resemble the
config here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we
can fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <
kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override
the url it hosts the endpoints at?

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login

API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"http://support.local.example.com","version":2,"description":"CF
v2 test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now
the uaac commands from above work and I can run 'uaac token owner get'.
I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become a
bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for them?
I'm going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can
fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com

wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override the
url it hosts the endpoints at?

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login

API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"http://support.local.example.com","version":2,"description":"CF
v2 test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now
the uaac commands from above work and I can run 'uaac token owner get'.
I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become a
bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for them?
I'm going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in cf-release
v215 and running it via tomcat with a custom config file, but I didn't
specify a database. I have both a cf and admin section in the uaa clients
config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can
fix that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override the
url it hosts the endpoints at?

One other note to whoever ends up working on this issue. It would be
great to add support in "cf push" and manifest commands as well.

Mike

On Fri, Sep 4, 2015 at 11:27 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Great! Thanks Dieu.

Mike

On Fri, Sep 4, 2015 at 10:46 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Shannon recently pulled the story over into the Routing team's tracker
[1] with the intention to submit a PR for it to the CLI team.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/story/show/93368928

On Fri, Sep 4, 2015 at 9:09 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Route path support has been in the CC and Router for several months
now. What is the status of getting these into the CLI? I did a quick
search for a CLI tracker story and couldn't find one.

Mike

Great! Thanks Dieu.

Mike

On Fri, Sep 4, 2015 at 10:46 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Shannon recently pulled the story over into the Routing team's tracker
[1] with the intention to submit a PR for it to the CLI team.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/story/show/93368928

On Fri, Sep 4, 2015 at 9:09 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Route path support has been in the CC and Router for several months
now. What is the status of getting these into the CLI? I did a quick
search for a CLI tracker story and couldn't find one.

Mike

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become a
bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

is there an example somewhere of a minimalist working config for them?
I'm going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in cf-release
v215 and running it via tomcat with a custom config file, but I didn't
specify a database. I have both a cf and admin section in the uaa clients
config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can
fix that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect
to /login. Doing it with /oauth/token gives a 401 unauthorized, same as the
cf cli.

What do you mean by deploy it as root "/"? As in, a override the
url it hosts the endpoints at?

is there an example somewhere of a minimalist working config for them? I'm
going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in cf-release
v215 and running it via tomcat with a custom config file, but I didn't
specify a database. I have both a cf and admin section in the uaa clients
config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect
to /login. Doing it with /oauth/token gives a 401 unauthorized, same as the
cf cli.

What do you mean by deploy it as root "/"? As in, a override the url
it hosts the endpoints at?

ok, that tells me that your configuration of the UAA clients is incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in cf-release
v215 and running it via tomcat with a custom config file, but I didn't
specify a database. I have both a cf and admin section in the uaa clients
config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect
to /login. Doing it with /oauth/token gives a 401 unauthorized, same as the
cf cli.

What do you mean by deploy it as root "/"? As in, a override the url
it hosts the endpoints at?

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url
it hosts the endpoints at?

curl exit code 6 means DNS failed. xip.io is flaky, so we this often in
our dev environments where our app domains tend to be HA_PROXY_IP.xip.io.

The CATS expect the apps to finish uploading, staging, and running in 2
minutes, although in reality this can take longer depending on the size of
the app, the number of dependencies it needs to fetch, etc. The CATS apps
are designed to generally get up and running within the 2 minute period,
but can't account for all possible types of network slowness.

openjdk is 43M and downloading on my machine takes about 7 seconds. In
your test output, we see it took 55 seconds. The last thing it was trying
to do was upload the 51M droplet, then at some point the 2min time limit
for everything to finish gets hit and the test fails. My guess is you're
experiencing network issues. If you can't fix those, you may want to
configure a more lenient push timeout in your acceptance_tests errand:


https://github.com/cloudfoundry/cf-release/blob/5fa14702bca4d36d1fdc7241c63d0b3e40dcbe90/jobs/acceptance-tests/spec#L69

Note, the above value is in seconds, so for e.g. if you want 3 minutes,
set it to 180.

On Fri, Sep 4, 2015 at 10:52 AM, Quintessence Anx <qanx(a)starkandwayne.com>
wrote:

Good afternoon!

Our CF deployment fails 4 of the CATs. I have put the errors and the full
output in a GIST here:

https://gist.github.com/qanx/677d64df27d911f39acd

Summary:

* There's a curl error even though the curl succeeds when I run it in
terminal.
* There's a Java buildpack error I can't figure out.
* There are two other buildpack errors, one each for the binary and
staticfile buildpacks. I believe these are expected, though, since we don't
have these two buildpacks in our deployment.

Does anyone know what could be causing these failures?

Thanks!

Quinn

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix that
later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

Hi,
(This is a post in proxy of my collegue.)

There are so many hard-coded dropsonde destinations (actually each of them
is a metron's listening port) in multiple repositories, while metron's
listening port itself is configurable.

Below is the list that we've found it is hard-coded:



Are they going to be finally configurable in the near future, or is there
any reason to hard-code them?

Thanks in advance.



-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474.html
Sent from the CF Dev mailing list archive at Nabble.com.