1

I've configured uaa for my vcap , I also successfully to register a new user into it,

azureuser@vcap:~/cloudfoundry/vcap/dev_setup/bin$ sudo vmc login

Attempting login to [http://paas.azure4j.us]

Email: test@meruvian.org

Password: **

Successfully logged into [http://paas.azure4j.us]

But when I try to "sudo vmc info"

Output is :

VMware's Cloud Application Platform

For support visit http://support.cloudfoundry.com

Target: http://paas.azure4j.us (v0.999)

Client: v0.3.23

Is it mean that I failed to login ?

Is there any problem with Uaa ?

3 Answers3

2

I think I fixed this issue for the present

So I disable uaa configuration on cloud_controller.yml

Then I can log in again with my username and password

uaa:

enabled: true --> false

url: http://chankillo.openpaas.or.id:8061/

resource_id: cloud_controller

token_secret: uaa_jwt_secret

client_secret: cloudcontrollersecret

token_creation_email_filter: [""

But I still dont know what is the effect of this to my vcap system or security ,

but thank you for all help :)

  • actually right now all users will be stored in cloud_controller's postgres DB, regardless of the cloud_controller.yml settings. – lalyos Nov 16 '12 at 21:34
0

Are you able to deploy applications to your VCAP instance? If you call vmc info with the --trace flag, what is the output?

Dan Higham
  • 3,974
  • 16
  • 15
  • when I use vmc version 0.3.10 or 0.3.15 , I can deploy my apps correctly , but it doesn't work on vmc version 0.3.23 dan CF plugin on Eclipse. – Toriq Pria Dhigfora Nov 07 '12 at 16:00
  • I know there are a few subtle incompatibilities between VCAP and certain versions of vmc. I have always found version 0.3.18 to be pretty reliable with private VCAP instances. Both VMC and VCAP are in constant development and the issues arise from time to time. – Dan Higham Nov 07 '12 at 17:10
  • So the most compatible version of VMC is 0.3.18 , okay , I can solve this for vmc , how about an eclipse , When I try to start connection into it an error occured , an output said : An internal error occurred during: "Connecting to server". A redirect is required to get the users approval – Toriq Pria Dhigfora Nov 08 '12 at 02:14
0

So first of all: before UAA was introduced, Cloud Controller (CC for short) was doing authentication itself alone, storing users in psql db.

Than later they figured out that CC should focus on Application/Servcice management and delegate authentication/authorization/usermanagement to a new component, which they named: User Account and Authentication (UAA) Server

UAA is mainly an oauth2 provider, which means giving tokens to clients. But client in oauth terms is an application like vmc/CC which acts on behalf of a user (resource owner in oauth terms)

echo 'select client_id, scope from oauth_client_details;' | sudo psql -U root uaa

    client_id     |                               scope                                
------------------+--------------------------------------------------------------------
 admin            | uaa.none
 vmc              | cloud_controller.read,cloud_controller.write,openid,password.write
 cloud_controller | uaa.none

UAA is also capable of Identity Management ie capable of storing users and their passord. They are implementing the SCIM standard (System for Cross-domain Identity Management). By default its uses postgres to store users:

echo 'select * from users;' | sudo psql -U root uaa

Actually right now on my vcap all users will be stored by cloud_controller's postgres DB, regardless of the cloud_controller.yml settings. But be aware that the CC - UAA connection is under heavy facelifting as you can see it in the git commits of the last couple of days:

In the last couple of days i was pulling the latest code from git several times, and sometimes new users were going into CC's db and sometimes they got to UAA's db. It also depends sometimes on vmc version ...

From you description i guess your users are in CC's db. You can check it by yourself. you can list users in cloud_controllers postgres db as:

echo 'select * from users;' | sudo -u postgres psql cloud_controller

Note the active column. If UAA is enabled, both DB stores the user, but its active=true in UAAdb and active=false in CCdb

So you safest bet is that you disable CC's UAA delegation, as figured, around line 77. of cloudfoundry/.deployments/devbox/config/cloud_controller.yml

uaa:
  enabled: false

after changing any configurationfile you have to restart the effected component in this case CC:

~/cloudfoundry/vcap/dev_setup/bin/vcap_dev restart cloud_controller
lalyos
  • 773
  • 5
  • 5