uaa target http://localhost:8080/uaa/ fails with:

GET /info HTTP/1.1
Host: localhost:8080
Accept: application/json
X-Identity-Zone-Subdomain:


HTTP/1.1 404
Date: Tue, 26 Jun 2018 17:00:45 GMT
Content-Length: 0



The target http://localhost:8080/uaa/ could not be set.

It appears that the uaa-cli is not using the root context /uaa when calling the /info endpoint.

For example, as github release artifacts like https://github.com/cloudfoundry/cli or to s3 like https://github.com/cloudfoundry/bosh-cli.

Pivotal uses GITBOT to synchronize Github issues and pull requests with Pivotal Tracker.
Please add your new repo to the GITBOT config-production.yml in the Gitbot configuration repo.
If you don't have access you can send an ask ticket to the CF admins. We prefer teams to submit their changes via a pull request.

Steps:

• Fork this repo: cfgitbot-config
• Add your project to config-production.yml file
• Submit a PR

If there are any questions, please reach out to [email protected].

Hello,

I'm having trouble logging in to an on-prem PCF environment using SSO. I've tested using an identical version of the CLI as a colleague who is not having the trouble, but using the slightly older version (6.48) didn't change any behavior.

The core issue is that I'm receiving an error, json: cannot unmarshal string into Go struct field InfoLinks.links.uaa of type ccv3.APILink in response to my login --sso request.

cf-cli: version 6.51.0+2acd15650.2020-04-07

Potentially Useful Details:

• I can log in to my public PWS account/org/space using a password.

• There is a corporate proxy in place - not sure if anything besides setting HTTP_PROXY and HTTPS_PROXY are required to make the magic happen?

• Login with --sso reports an SSL Certificate problem, which is spurious. This error is NOT reported on any of my colleagues' machines.
  > cf login -a <https-url> --sso
> Invalid SSL Cert for <https-url> TIP: Use 'cf login --skip-ssl-validation' to continue with an insecure API endpoint

• Login with the skip-ssl-validation returns the following:
  > cf login -a https://login.system.pcfpre-ewd.cloud.boeing.com --sso --skip-ssl-validation
> json: cannot unmarshal string into Go struct field InfoLinks.links.uaa of type ccv3.APILink

• setting CF_TRACE=true, I get the following output prior to the above error message (with the full URLs redacted):
  `RESPONSE: [2020-07-22T08:45:49-05:00]
  HTTP/1.1 200 OK
  Cache-Control: no-store
  Content-Language: en-US
  Content-Length: 764
  Content-Type: application/json;charset=UTF-8
  Date: Wed, 22 Jul 2020 13:45:48 GMT
  Set-Cookie: X-Uaa-Csrf=68OdX8qO4cg6BY9zoabl1K; Max-Age=86400; Expires=Thu, 23-Jul-2020 13:45:49 GMT; Path=/; Secure; HttpOnly
  Strict-Transport-Security: max-age=31536000 ; includeSubDomains
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  X-Vcap-Request-Id: 6a443ed4-7666-4472-5c4a-2a9aac3d5321
  X-Xss-Protection: 1; mode=block
  {

  "app": {
  "version": "73.4.24"
  },
  "commit_id": "a91c1a7",
  "entityID": "",
  "idpDefinitions": {
  "https://saml...": "https://login...?returnIDParam=idp&entityID=http://login...&idp=https://saml...&isPassive=true"
  },
  "links": {
  "login": "https://login...",
  "uaa": "https://uaa..."
  },
  "prompts": {
  "passcode": [
  "password",
  "Temporary Authentication Code ( Get one at https://login.../passcode )"
  ],
  "password": "[PRIVATE DATA HIDDEN]",
  "username": [
  "text",
  "Email"
  ]
  },
  "showLoginLinks": true,
  "timestamp": "2020-05-19T19:05:36+0000",
  "zone_name": "uaa"
  }`

Version

$ uaa version
0.7.0 8b3ea1f

Command

uaa list-clients

Returns

An unknown error occurred while parsing response from https://uaa.run.markspcffoundry.com/oauth/clients?count=100&sortOrder=ascending&startIndex=1. Response was <18150 characters of redacted json>: json: cannot unmarshal string into Go struct field Client.resource_ids of type []string

The <18150 bytes of redacted json> is from me, not the uaa client.

If I take the 18150 characters of json and pipe through jq it processes successfully.
If I run the command a second time with the --verbose flag, and compare the json from that output to the json in the error message, it is a perfect match.

Many commands do not pass back the UAA API error, and require the user to run the command again with --verbose.

Instead, if a UAA API error is returned could all commands please return the error without requiring --verbose?

This is similar PR opened for UAAC at cloudfoundry/cf-uaac#64

When creating a client using the latest build of UAA, the scopes are not validated. The UAA is creating the scope with any string we give rather than validating the scopes existence within UAA. Is it any limitation that UAA has to validate scopes?, as grant types are being validated by the CLI at the same time.

I want to log in to the UAA used by my cloudfoundry to perform some basic user management.

Getting Tokens:
  get-authcode-token            Obtain an access token using the authorization_code grant type
  get-client-credentials-token  Obtain an access token using the client_credentials grant type
  get-implicit-token            Obtain an access token using the implicit grant type
  get-password-token            Obtain an access token using the password grant type
  get-token-key                 View the key for validating UAA's JWT token signatures
  get-token-keys                View all keys the UAA has used to sign JWT tokens
  refresh-token                 Obtain an access token using the refresh_token grant type

All of these descriptions expect a lot of context about UAA.

Is it possible to have a simple login flow instead, just like when I go to the UAA web interface?

To support client operations such as get-client or create-client

I've built uaa with golang 1.10 and I tried the following env vars but uaa is not using the socks5 tunnel. Could we please add support (or is there a diff env var I should use for socks5 proxies?)

export HTTP_PROXY=socks5://localhost:9999
export HTTPS_PROXY=socks5://localhost:9999
uaa target https://10.10.1.4:8443 --skip-ssl-validation

Uaa curl does not work with any host but the targeted UAA.

uaac curl https://not-uaa-host.example.com is handy with workflows where you use uaa to grab a bearer token and then issue curl requests that utilize that token. For example https://docs.pivotal.io/platform/healthwatch/1-8/api/free-chunks.html#get

Here's a sample that doesn't work so well

$ uaa curl https://healthwatch-api.sys.example.com/v1/info -v

GET /https:/healthwatch-api.sys.example.com/v1/info HTTP/1.1
Host: login.sys.example.com
Authorization: Bearer abcd

My colleagues and I love using this over uaac-- especially since starkandwayne has made it available via package management.

However, I'm still inclined to ask whether this project will be adopted by the community and vendors. Apologies if this is too vague, but:

• How likely is it that this project will replace uaac over time?
• Why hasn't there been as strong adoption of this project as a replacement for uaac? (Are there technical reasons, or just by virtue of uaac being the status quo?)

Can you hear me now?

The url https://github.com/cloudfoundry-incubator/uaa-cli/releases/latest redirects to tag/release 0.0.1. Please update the repo to point to the newest release.

Adding a pre_release: true to the concourse/github-release for uaa-cli allows me to work around the issue.

The uaa add-member method does not have a corresponding uaa remove-member method yet.

create this issue because finally uaa-cli cannot create context with clients in uaa where a special character is in secret.

Thus, uaa-cli use go-uaa use oauth2 from go, it will be hard to solve.
Issue in go-uaa is cloudfoundry/go-uaa#10

From my point of view cloudfoundry/go-uaa#10 should be solved but technically you can do a workaround here, therefore an extra issue here

Good day, I am trying to figure out the difference between the Ruby uaac and Go uaa when using curl to update OpsMan authentication settings.
Below env vars are used in both cases:

# Env Vars
ENV_NAME=sandbox
opsman_password=$(credhub get -n "/concourse/${ENV_NAME}/opsman_password" -q)
decryption_passphrase=$(credhub get -n "/concourse/${ENV_NAME}/opsman_decryption_passphrase" -q)
unlock_user_password=$(credhub get -n "/concourse/${ENV_NAME}/opsman_unlock_user_password" -q)
payload="{
  \"authentication\": {
    \"decryption_passphrase\": \"${decryption_passphrase}\",
    \"identity_provider\": \"internal\",
    \"admin_user_name\": \"admin\",
    \"admin_password\": \"${opsman_password}\",
    \"admin_password_confirmation\": \"${opsman_password}\"
  }
}"

This works (Ruby uaac):

uaac target https://pcf.${ENV_NAME}.westeurope.api.mtn.com/uaa
uaac token owner get opsman unlock_user -s '' -p "${unlock_user_password}"

uaac curl -X PUT -H "Content-type: application/json" https://pcf.${ENV_NAME}.westeurope.api.mtn.com/api/v0/settings/authentication -d "${payload}"

I get:

--snip--
200 OK
--snip--

and in the OpsMan access.log:

155.93.175.238 - opsman [20/Apr/2021:10:09:35 +0000] "POST /uaa/oauth/token HTTP/1.1" 200 2532 "-" "HTTPClient/1.0 (2.8.3, ruby 2.5.1 (2018-03-29))"
155.93.175.238 - - [20/Apr/2021:10:09:51 +0000] "PUT /api/v0/settings/authentication HTTP/1.1" 200 12 "-" "Ruby"

This does not work (Go uaac):

./uaa target https://pcf.${ENV_NAME}.westeurope.api.mtn.com/uaa
./uaa get-password-token opsman -s '' -u unlock_user -p "${unlock_user_password}"

./uaa curl -X PUT -H "Content-type: application/json" https://pcf.${ENV_NAME}.westeurope.api.mtn.com/api/v0/settings/authentication -d "${payload}"

I get:

--snip--
        <div class="alert alert-error">
            <p>Invalid login attempt, the request does not meet our security standards and may indicate that the action was not originated by you. Please try again.</p>
        </div>
--snip--

and in the OpsMan access.log:

155.93.175.238 - opsman [20/Apr/2021:09:55:09 +0000] "POST /uaa/oauth/token HTTP/1.1" 200 2516 "-" "Go-http-client/1.1"
155.93.175.238 - - [20/Apr/2021:09:57:41 +0000] "PUT /uaa/https:/pcf.sandbox.westeurope.api.mtn.com/api/v0/settings/authentication HTTP/1.1" 302 0 "-" "Go-http-client/1.1"
155.93.175.238 - - [20/Apr/2021:09:57:41 +0000] "GET /uaa/login?error=invalid_login_request HTTP/1.1" 200 49404 "https://pcf.sandbox.westeurope.api.mtn.com/uaa/https:/pcf.sandbox.westeurope.api.mtn.com/api/v0/settings/authentication" "Go-http-client/1.1"

After merging #6 , I am getting failing test cases and my local files are being modified when running make && make install.

$ make && make install
...
Summarizing 4 Failures:

[Fail] ListUsers [It] understands the --zone flag
/Users/drnic/Projects/gopath/src/github.com/cloudfoundry-incubator/uaa-cli/vendor/github.com/onsi/gomega/ghttp/handlers.go:45

[Fail] ListGroups [It] understands the --zone flag
/Users/drnic/Projects/gopath/src/github.com/cloudfoundry-incubator/uaa-cli/vendor/github.com/onsi/gomega/ghttp/handlers.go:45

[Fail] ListUsers [It] executes SCIM queries based on flags
/Users/drnic/Projects/gopath/src/github.com/cloudfoundry-incubator/uaa-cli/vendor/github.com/onsi/gomega/ghttp/handlers.go:45

[Fail] ListGroups [It] executes SCIM queries based on flags
/Users/drnic/Projects/gopath/src/github.com/cloudfoundry-incubator/uaa-cli/vendor/github.com/onsi/gomega/ghttp/handlers.go:45

Ran 188 of 188 Specs in 6.365 seconds
FAIL! -- 184 Passed | 4 Failed | 0 Pending | 0 Skipped --- FAIL: TestCmd (6.37s)
FAIL

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   Gopkg.lock
	modified:   cmd/add_member.go
	modified:   cmd/create_user.go
	modified:   cmd/deactivate_user.go
	modified:   cmd/errors.go
	modified:   cmd/get_password_token.go
	modified:   cmd/get_user.go
	modified:   cmd/refresh_token.go
	modified:   cmd/root.go
	modified:   cmd/set_client_secret.go
	modified:   cmd/target.go

This CLI is obviously a wonderful future direction for UAA administration. Its so much nicer than cf-uaac to install and use. Is there an ETA for when a new burst of R&D, curation of issues & PRs, and with new releases, might occur?

Executing uaa get-client identity against a Tanzu Application Service installation results in the following error:

json: cannot unmarshal string into Go struct field Client.resource_ids of type []string

The raw UAA response object contains a single string instead of an array of resource_ids. Here's the raw response:

{
    "scope": [
        "cloud_controller.admin",
        "cloud_controller.read",
        "cloud_controller.write",
        "openid",
        "zones.*.*",
        "zones.*.*.*",
        "zones.read",
        "zones.write",
        "scim.read"
    ],
    "client_id": "identity",
    "resource_ids": "none",
    "authorized_grant_types": [
        "authorization_code",
        "client_credentials",
        "refresh_token"
    ],
    "redirect_uri": [
        "https://p-identity.sys.example.com/dashboard/",
        "https://p-identity.sys.example.com/dashboard/**"
    ],
    "autoapprove": true,
    "authorities": [
        "zones.read",
        "zones.write",
        "scim.zones",
        "uaa.resource",
        "uaa.admin",
        "cloud_controller.admin"
    ],
    "lastModified": 1588509584000
}

This is the only client that seems to have this issue. The UAA API clearly documents that client resource_ids should be an array.

The project needs cloudfoundry-community/uaa

Love the update/patches!

We're experiencing errors running the new CLI in some environments.

uaa: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by uaa)
uaa: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by uaa)

The changes in GOLANG 1.20 require the user to provide a larger runtime VS GOLANG packaging/delivering the runtime components with each release.

OR

set CGO_ENABLED=0 to disable the CGO runtimes and use pure GOLANG.

In order to promote the usage of the golang uaa-cli, consider removing the word "Experimental" in the part of the project description's "Experimental CLI for UAA written in Go."

*and from the README.md

👍

If I've already logged in with uaa v0.0.1, and then try to upgrade to master branch I am rewarded with an ugly panic. Perhaps instead, politely suggest to the user to re-authenticate/re-login if ~/.uaa/config.json exists, but the token is invalid, etc.

$ uaa version
0.0.1

$ VERSION=0.0.1 make build
$ build/uaa version
0.0.1 aa21f51
$ build/uaa clients

panic: must supply a valid token

goroutine 1 [running]:
code.cloudfoundry.org/uaa-cli/cmd.GetAPIFromSavedTokenInContext(0x1d)
	/Users/drnic/Projects/gopath/src/code.cloudfoundry.org/uaa-cli/cmd/api_client.go:20 +0x9fd
...

There is a tap in cloudfoundry: https://github.com/cloudfoundry/homebrew-tap

It would be nice to install this with a nice brew install uaa-cli

Currently uaa target only supports --skip-ssl-validation to ignore custom root certificates. Could we add support for a --ca-cert flag too please?

Related to cloudfoundry/go-uaa#5

In the ruby based uaa client you need username, password, email, in this new go version you also need family name and given name. This will make it harder to update automation scripts using it. Also not every user needs two names ( or any! ), for example robot users, also while rare some people only have one name.

ruby:

uaac user add test -p test --emails [email protected]
user account successfully added

go:

/tmp/uaa-linux-amd64-0.8.0 create-user test -p test --email [email protected]
Missing argument `familyName` must be specified. 

When uaa-cli extracted the client code into a library we migrated to version 0.0.6. This version had removed pagination for the clients/users/groups endpoint in favor of traversing the paged results (e.g. the cli will list every user).

We would like to have pagination back. We should bump github.com/cloudfoundry-community/go-uaa to version 0.0.8

Hello,
we are trying to move vom uaa ruby client to uaa go client in a corporate environment on Debian Linux 11.8. We can´t use a newer Debian in cause of company guidelines and working as normal user not as root or with sudo.

>> ./uaa-linux-amd64-0.13.0 target https://uaa.restofuaaurl.de
Target set to https://uaa.restofuaaurl.de

>>  ./uaa-linux-amd64-0.13.0 get-client-credentials-token admin -s our_secret_string
Access token successfully fetched and added to context.

./uaa-linux-amd64-0.13.0 list-clients

And now the output is not a wellformed json as expected rathern an malformed output beginning with An unknown error occurred while parsing response from https://uaa ... and ending with json: cannot unmarshal string into Go struct field Client.resources.resource_ids of type []string This occours in all our environments.

Hope the infos are helpful and a fixed version is coming out soon ;)

Thanks in advance & Best regards

Currently, this has been allowing faulty requests to go through CI pipelines, and we've had to do some manual error handling.

I'm not sure what other clis have done as far as cloudfoundry cli convention goes.