Start a new topic

Best practices for security scope-based structure field visibility

 Hello,


This question is an enquiry for advice above everything else.


Let's say that I am developing a web forum api and I have ended up with following RAPID-ML model for user record info access


 

rapidModel TestForum
	resourceAPI MyResourceAPI baseURI "http://my-namespace.com"
		secured by
			UserLogin
				authorized for scopes
					anyone
					
		objectResource User type User
			URI /user-info/{id}
				required templateParam id bound to property id
			method GET getUserInfo
		
	dataModel db
		structure User
			id: string
			first_name: string
			last_name: string
			email: string
			nickname: string

	securitySchemesLibrary WebsiteSecurity
		/** Main website security method  */
		securityScheme UserLogin
			type basic
			methodInvocation
				requires authorization
					required param auth_tkt type string in header
				errorResponse statusCode 401 
			
			defines scopes
				/** Platform admin  */
				system_admin
				
				/** This organisations admin (either provider or client) */
				admin
				/** unpriviledged org user  */
				user
				/** anyone - even users who haven't registered yet */
				anyone

 

What is the most elegant/future-proof way of signifying different sets of fields returned depending on the actual authorisation scope of the client?


E.g. if I want to signal that the system will only return "nickname" for anyone security scope, "nickname & first_name" for user security scope and full record info for any of admin scopes?


Creating separate api endpoints for the purpose seems to be bit of an overkill and is likely to lead to spaghetti implementation.



1 Comment

Ilja, great question. 


RAPID-ML doesn't currently provide a way to include or exclude data properties from a response, based on runtime variables like security role.  Incidentally, OpenAPI doesn't support this either, though OpenAPI v3 does support a limited form of content negotiation by media type. 


We have done some preliminary design work to filter content based on a notion of context.  See the discussion here:


https://support.reprezen.com/support/discussions/topics/24000004846


As described there, context is an attribute of an API, specified at design time. But dynamic contexts could also be worked into a design like this. 


This is something we'd like to do, though we don't have a timeframe for it. If this has real commercial value to your organization, please feel free to get in touch, and we can talk through some options. 


Ted Epstein |   |       skype:ted.epstein


Login or Signup to post a comment