Releases: cloudfoundry/uaa
1.8.3 Release Notes
/ids/Users endpoint protected by a scope
Previously, any valid token was allowed access to translate a username to a id or vice versa. It is now protected by the scim.userids scope. Security is further tightened by checking the scope as well limiting filtering possibilities.
Externalize default scopes
Non UAA scopes, were previously defined in the oauth-endpoints.xml. Client scopes can now be configured in the uaa.yml instead of relying on our XML file.
Refactor /Groups/External APIs
Endpoints that are more RESTful have been added for listing, updating and deleting external group mappings.
Stories Completed
Features
Externalize default scopes
Protect /ids/Users by scope
Refactor API
1.8.0 Release Notes
Scope wildcards
In UAA we now support client scopes to have a wildcard. Imagine this scenario
Client Scopes
- cloud_controller.*
User Joe
- cloud_controller.read
- cloud_controller.write
User Mary
- cloud_controller.read
- cloud_controller.write
- cloud_controller.admin
When respective user requests a token, Joe will receive cloud_controller.read/write and Mary will receive cloud_controller.read/write/admin scopes.
To receive these scopes, the token/authorize request
- may not contain any scopes to receive the default intersection of scopes between client and user
- can include a wild card scope, cloud_controller.*, but it has to match the scope of the client
- can include a specific scope, cloud_controller.read, that matches a user assigned scope
The wildcard matching is very simple. An asterisks, *, character represents a wild card. The wild card will never reach beyond a dot, ., that is considered a scope delimiting character.
For matching examples, take a look at the following tests
- Wild card matching by the UaaAuthorizationRequestManager
- Wildcard to Regular Expression translation
- Token mock tests
Limitations
User scopes may not contain wild cards. In a user scope, a wildcard will not be treated as a special character.
Extract Mail Attribute from LDAP user
A very simple feature has been implemented to extract the LDAP mail attribute from a user's record when a user is authenticated against LDAP
This feature simply looks at the LDAP record, extracts the 'mail' field and picks the first address on file. Currently we have not implemented a more advanced feature to select a specific email address if multiple exist. However, from the authentication, we do get all the email addresses and populate them into the Ldap User Details object.
When the user gets converted to a UAA record, it selects the first email address on file.
Ldap Documentation
Read it now
Gradle
UAA now builds with gradle instead of maven. This simplifies the build process, as one can now build from scratch, and run the uaa, app, and api apps with a simple
./gradlew run
Unit tests can be run with ./gradlew test
, and integration tests with ./gradlew integrationTest
War and Jar files can be built with ./gradlew assemble
Tigthen security around /token endpoints
We have tightened security in the /oauth/token endpoint. Previously a token with a scope of oauth.<anything>, essentially having audience=oauth, was allowed to issue tokens without requiring user password or client secrets. We believe this scope is too broad to be allowed. Currently the login-server uses a scope of oauth.login for trusted endpoints, and even then, client_secret is required to issue a password grant token.
Stories Completed
Features
Allow client scopes/authorities to have wildcards
Expand oauth_client_details scope and authorities columns
Extract mail attribute from an LDAP user when user stored in UAA
Group memberships are tracked by origin
Email address is updated each time an LDAP user authenticates
Security tightened around token endpoints
External group map endpoint
UAA 1.7.2 Release - Chained Authentication
Move all LDAP Authentication to UAA
1c400c2
Make the UAA multi tenant
Two columns have been added to the UAA.users table
- origin - the source of the users
- external_id - if the user has a unique ID in the other repository, like LDAP DN
This means that the user_id should be used as the identifier for a user, not the username
1a63add
Implement correct SCIM filtering according to the spec
http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resources
af4860a
Backwards compatibility for filters surrounded with single quotes "userName eq 'marissa'" have been retained
Support for LDAP groups
LDAP Groups can be mapped to scopes as
- group name is the scope name
- group DN maps to a scope(group_id) in the external_group mapping
Nested LDAP groups are supported
e534512
Stories Completed
Bugs
Remove test classes from src/main/java
SCIM Filter should be backwards compatible, support single quote
Change password link should only be available if the user origin=UAA
Username should not be case sensitive
Fix pagination of the SCIM user endpoint
Proper SCIM parsing to support single quotes
Features
Keystone authentication support
LDAP Authentication in CF is part of the UAA job
Move external authentication is part of the UAA instead of Login server
Support multi tenancy for users