dynamic authorizer based only on authrole?

#1

In crossbar, is the dynamic authorizer only based on the authrole?

The documentation shows that as an example:

http://crossbar.io/docs/Authorization/

But, I’m wanting to know if that is the only option?

I’m planning to handle authorization for RPC calls inside the call itself. I’m thinking code that does something like:

if (!some_function_to_grant_access(auth_id)) {

return com.domain.error.access_denied message

}

That code would be at the top of all my RPC calls and would handle authorization for the ‘call’ action of all inbound calls.

Today, I have the following static authorization defined:

{

"id" : "frontend",

"name" : "frontend",

"permissions" : [

	{

		"uri" : "com.epygi.*",

		"publish" : false,

		"subscribe" : true,

		"call" : true,

		"register" : false

	}

]

}

Now, here’s what I’m planning for all 4 actions that might be performed by a “front-end” client:

publish - front-end sessions will not be allowed to publish. This action could be blocked statically by the authrole by setting “publish: false”

register - front-end sessions will not be allowed to register. This action could be blocked statically by the authrole by setting “register: false”

call - authorization will be handled as defined above inside each rpc call. At the router level, this action could be allowed statically by setting “call: true”. It would be nice if Crossbar could be configured to automatically send authid to the callee without requiring caller or callee to set “disclose_me” or “disclose_caller” values. I’d like this turned on at the router itself … see my other (ahem non-answered) posts about this.

subscribe - I want per-module dynamic functions to handle this. It would be nice if I could map uris onto authorization functions like this:

subscribe: com.domain.special.*, com.domain.special.authorize

subscribe: com.domain.other.*, com.domain.other.authorize

subscribe: com.domain.third.*, com.domain.third.authorize

If I CAN NOT have that level of control, I can work around it by defining a single authorize function like this:

“roles” : [

{

“id” : “frontend”,

“name”: “frontend”,

“authorizer”: “com.example.authorize”

}

But that forces ALL FOUR actions and ALL subscribe namespaces to use the same single authorize function.

The documentation says: “The idea is to have the majority of scenarios covered using Static Authorization, and handle special requirements and scenarios using Dynamic Authorization.”

… so that makes me really want to use static authorization where possible and only resort to dynamic authorization if I really must. I’m therefore wanting to set Dynamic Authorization for a authrole/action combination and not just authrole.

Should I be concerned about doing it for all 4 actions? … when the authorization function would end up looking like this:

def custom_authorize(session, uri, action):

IF ‘call’ == action THEN

return True

END IF

IF ‘register’ == action or ‘publish’ == action THEN

return False

END IF

return session.call( get_custom_authorizer_uri_from_uri(uri), [session, uri, action])

Ignore all the “syntax” above. I’m just pseudo-coding it for brevity to convey the intent. Where the ‘get_custom_authorizer_uri_from_uri(…)’ method would basically append “authorizer” to the end of the “namespace” from the original call … like:

com.domain.special.func_one —> com.domain.special.authorizer

com.domain.other.func_two —> com.domain.other.authorizer

com.domain.third.who_cares_what_name_is_here —> com.domain.third.authorizer

What you you think?

– Dante

0 Likes