cloudfoundry / uaa

CloudFoundry User Account and Authentication (UAA) Server
Apache License 2.0
1.59k stars 827 forks source link

*Bug* - External ID is currently not searchable although it should be #900

Closed smoser-ibm closed 4 years ago

smoser-ibm commented 6 years ago

What version of UAA are you running?

{"app":{"version":"4.11.0"},"links":{"uaa":"https://uaa....

How are you deploying the UAA?

I am deploying the UAA using cf-deployment

What did you do?

If possible, provide a recipe for reproducing the error. Exact curl or uaac commands with verbose output are helpful. If your problem is configuration-related, please include portions of your uaa.yml or bosh deployment manifest that you believe may be relevant (but do not divulge secrets!)

What did you expect to see? What goal are you trying to achieve with the UAA?

According to UAA documentation, external_id is a searchable attribute. See also https://github.com/cloudfoundry/uaa/blob/develop/docs/UAA-APIs.rst#a-note-on-filtering

" [...] The following column names can be used for querying a user

[...]

  1. Get Users (working)

curl -H "Authorization: Bearer $TOKEN" -H "Accept: application/json" "https://uaa.ng.bluemix.net/Users?filter=userName+eq+%22Martin.Smolny%40de.ibm.com%22"

{"resources":[{"id":"20523bc9-61ba-4224-9176-4590d6bed26a","meta":{"version":4,"created":"2014-07-21T08:28:35.420Z","lastModified":"2014-08-15T02:51:22.340Z"},"userName":"Martin.Smolny@de.ibm.com",...}

  1. Get Users (bug)

external_id, as documented:

curl -H "Authorization: Bearer $TOKEN" -H "Accept: application/json" "https://uaa.ng.bluemix.net/Users?filter=external_id+eq+%22abc%22"

{"error_description":"Invalid filter expression: [external_id eq \"abc\"] [created]","error":"scim","message":"Invalid filter expression: [external_id eq \"abc\"] [created]"}

externalid without underscore:

curl -H "Authorization: Bearer $TOKEN" -H "Accept: application/json" "https://uaa.ng.bluemix.net/Users?filter=externalid+eq+%22abc%22"

{"error_description":"Invalid filter expression: [externalid eq \"abc\"] [created]","error":"scim","message":"Invalid filter expression: [externalid eq \"abc\"] [created]"}

for comparison the attribute phonenumber that is also documented as searchable:

curl -H "Authorization: Bearer $TOKEN" -H "Accept: application/json" "https://uaa.ng.bluemix.net/Users?filter=phonenumber+eq+%22abc%22"

{"resources":[],"startIndex":1,"itemsPerPage":100,"totalResults":0,"schemas":["urn:scim:schemas:core:1.0"]}

cf-gitbot commented 6 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/160536442

The labels on this github issue will be updated when the story is started.

sreetummidi commented 6 years ago

@smoser-ibm external id is a legacy field and we plan to deprecate and remove it. Its not of consequence in UAA flows.

smoser-ibm commented 6 years ago

@sreetummidi Please don't! I do have a requirement that I can store an external reference to a UAA record, and all I was asking is that field is searchable like it is documented. Let me know if you need more detailled explanation of the requirement, but in fact I think UAA has all of it already except that the field is not searchable (which is should be according to the doc and according to my requirement)

gmendel commented 6 years ago

There must be a way to link UAA entries to formal ID. userName is not always always immutable.

sreetummidi commented 6 years ago

I see. We can retain it. @smoser-ibm PR would be advisable if its time sensitive.

smoser-ibm commented 6 years ago

sure @sreetummidi . Can you please reopen this one then ? I'll check how timing is on this and who'd be able to PR it in case it is

cf-gitbot commented 6 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/160662079

The labels on this github issue will be updated when the story is started.

metacubed commented 6 years ago

@sreetummidi the externalId field is part of the SCIM core schema for User resources: https://tools.ietf.org/html/rfc7643#section-3.1

We rely on this field being present, please keep this field and add the search capability.

dlouzan commented 5 years ago

As a followup to @sreetummidi, although the rfc for SCIM 1.1 lists this field as optional, it is incredibly valuable for integration scenarios.

shamus commented 4 years ago

Closing due to inactivity.