Require cloud_controller.read access(or equivalent) to access list endpoints.

[Benjamintf1]

Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

• A short explanation of the proposed change:

Require cloud_controller.read access(or equivalent) to access list endpoints.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[Benjamintf1]

Two things to note:

1. users with write permissions but not read permissions can no longer read as well in this pr.

2. unauthenticated users can access marketplace without permissions if the toggle for the marketplace visibility is turned off, unlike other endpoints.

• Now it seems to me that this is possibly an oversight brought by interaction between the list endpoint logic and the filtering logic. We have one layer of filters that effects permissions that looks at tokens and one that looks at users. The token logic isn't implemented because we assume that any filtering will happen at the user logic level, and the user logic filtering level doesn't actually effect "public" marketplace values. This means that unauthenticated users can access marketplace values. - Now If I had to guess, we "papered over" this problem with the "allow unauthenticated users" toggle. Given it exists, it seems resonable to honor that contract, but at some point it seems like we should possibly eol that toggle and just make sure that only cf users can access "public"(aka, for all orgs and spaces) information always.

[Gerg]

Looking into this PR sent me down a rabbit hole about the *_with_token methods on the access classes.

In summary, they were first introduced by #221 for this story.

It appears the main difference between the two methods is what error is returned: InsufficientScope vs NotAuthorized.

[Gerg]

In general, is it necessary to fill in this logic in both index? and index_with_token? for all these access classes? From looking at

cloud_controller_ng/app/controllers/base/model_controller.rb

Lines 239 to 251 in 7b1848e

	def validate_access(operation, obj, *)
	if @access_context.cannot?("#{operation}_with_token".to_sym, obj)
	obj = obj.to_s if obj.is_a? Class
	logger.info('allowy.access-denied.insufficient-scope', op: "#{operation}_with_token", obj: obj, user: user, roles: roles)
	raise CloudController::Errors::ApiError.new_from_details('InsufficientScope')
	end
	return unless @access_context.cannot?(operation, obj, *)
	obj = obj.to_s if obj.is_a? Class
	logger.info('allowy.access-denied.not-authorized', op: operation, obj: obj, user: user, roles: roles)
	raise CloudController::Errors::ApiError.new_from_details('NotAuthorized')
	end

the index_with_token? is called first and the request will never reach index?. Also the index_with_token? error seems more appropriate for this case (though, we aren't very consistent with which access method we use, in general).

[Benjamintf1]

Broadly speaking, it seems to me both safer, and moreso, consistant for us to double up on both.

It doesn't really cost anything for us to have the same thing both places, and even before the change, the same comment about how "filtering happens later" in the old code was often in both places anyways, so I just went with both.

[Benjamintf1]

I definatly considered it, but it doesn't seem to matter much so I made a, I think, quick and reasonable choice and moved on. It also avoids broader re-works for a more narrow changeset.

Do you have any concerns with having both specifically? What kind of problem will that introduce?

[Gerg]

My main concern is adding code that isn't necessary to achieve the desired behavior and may never execute.

I think the "original sin" was 1d6b036, which inlined all these methods (not disparaging; it made sense at the time). These methods made sense as base class defaults, but not necessarily included in each access class.

That said, especially since this is v2 only, it's also reasonable to just continue the current pattern, messy as it is. I'm not going to block on this.

[Gerg]

I'm not super excited about including business logic here, but there is some prior art for checking feature flags in the v2 access classes: https://github.com/search?q=repo%3Acloudfoundry%2Fcloud_controller_ng+path%3A%2F%5Eapp%5C%2Faccess%5C%2F%2F+FeatureFlag&type=code

If this logic needs to go here, can/should we remove the corresponding logic in the controller?

cloud_controller_ng/app/controllers/services/services_controller.rb

Lines 28 to 39 in 7b1848e

	allow_unauthenticated_access only: :enumerate
	def enumerate
	if SecurityContext.missing_token?
	raise CloudController::Errors::NotAuthenticated if VCAP::CloudController::FeatureFlag.enabled?(:hide_marketplace_from_unauthenticated_users)
	@opts.delete(:inline_relations_depth)
	elsif SecurityContext.invalid_token?
	raise CloudController::Errors::InvalidAuthToken
	end
	super
	end

[Benjamintf1]

If this logic needs to go here, can/should we remove the corresponding logic in the controller?

possibly? Do you want me to?

having this logic in the access controller

I'd rather there not be that code in the access controller at all tbh, but i would have done that by just, never anymore allowing unauthorized users to access the marketplace endpoint. Given we have what I'd, honestly consider a "compatibility flag" more then a "feature flag"(as I mentioned in my comment), I figured I should try to respect that flag unless we're thinking we're ok with dropping it.

[Gerg]

Is it ever possible for the services controller code to execute? If the InvalidAuthToken and InvalidAuthToken cases are already handled elsewhere, then I think we should delete the vestigial code.

[Benjamintf1]

I'll try and look into this and remove the redundancy.

[Benjamintf1]

hmmm. I did "quick" checks. I'll do more tomorrow. It appears to be not possible to quickly remove.

[Benjamintf1]

I'm doing research, It seems like service and service_plan access effect /v2/service calls, but weirdly enough not /v2/service_plan calls? I'm not sure what to do.