problem with dynamic authentication, realms, and transports

#1

For my transport, I have identified a custom authenticator like:

“ws” : {

	"type" : "websocket",

	"auth" : {

		"wampcra" : {

			"type" : "dynamic",

			"authenticator" : "com.domain.session.authenticate"

		}

	}

},

In order for this authenticator to exist, I have created a client that defines this RPC call. However, the client that defines the call needs to connect to the Crossbar router using a different transport that has static authentication assigned. Upon connecting to the other transport, I need to provide the “realm” to connect to.

Suddenly, the custom authenticator only exist on that realm!

Now, when I connect to a different realm, I get an error like this:

WebSocket transport receive [3,{“message”:“no procedure ‘com.domain.session.authenticate’ registered”},“wamp.error.no_such_procedure”]

I guess that means I need to define this custom authentication method inside each realm? Meaning I need to create multiple backend clients (one for each realm)? Can’t the authenticator client connect to “all realms” for purpose of defining the same function across all realms?

– Dante

0 Likes

#2

Hi Dante,

there is indeed a 1-to-1 relationship in that each session can only be connected to one realm.

To use a single authenticator component for multiple realms, you can create several sessions, each to one of the realms you wish to cover, and then register the authenticator method for each. There’s no need to have multiple clients - a single client is not limited to a single WAMP connection/session!

Regards,

Alex

···

Am Freitag, 16. Januar 2015 07:16:10 UTC+1 schrieb Dante Lorenso:

For my transport, I have identified a custom authenticator like:

“ws” : {

  "type" : "websocket",
  "auth" : {
  	"wampcra" : {
  		"type" : "dynamic",
  		"authenticator" : "com.domain.session.authenticate"
  	}
  }

},

In order for this authenticator to exist, I have created a client that defines this RPC call. However, the client that defines the call needs to connect to the Crossbar router using a different transport that has static authentication assigned. Upon connecting to the other transport, I need to provide the “realm” to connect to.

Suddenly, the custom authenticator only exist on that realm!

Now, when I connect to a different realm, I get an error like this:

WebSocket transport receive [3,{“message”:“no procedure ‘com.domain.session.authenticate’ registered”},“wamp.error.no_such_procedure”]

I guess that means I need to define this custom authentication method inside each realm? Meaning I need to create multiple backend clients (one for each realm)? Can’t the authenticator client connect to “all realms” for purpose of defining the same function across all realms?

– Dante

0 Likes

#3

Hi Dante,

there is indeed a 1-to-1 relationship in that each session can only be connected to one realm.

To use a single authenticator component for multiple realms, you can create several sessions, each to one of the realms you wish to cover, and then register the authenticator method for each. There’s no need to have multiple clients - a single client is not limited to a single WAMP connection/session!

Alex,

I understand what you are saying, but I do not think this is optimal design. There must be something more that can be done about this. If you are thinking modularly, ideally, you would create an authentication function just once and plug that into the router. The authentication function would support an infinite number of realms as the ‘global’ authenticator function.

Alternatively, if there is no such concept as a global authenticator function, then it should be possible to define a realm-specific authenticator function. As it is now, the “authenticator” name I define in the transport will be the same name used in all realms and unfortunately, I am now forced to build a separate connection/session for each realm the router serves. (note: I do like your suggestion to multiply the connection/session inside the same client vs creating multiple clients, and though this is better than what I was thinking, it’s still not ideal).

If the router services 10 realms, the authenticator must be modified to connect to each realm separately in order to offer the same function to each realm. This certainly doesn’t scale as realm count expands, and worse, all realm names must be manually added to this authenticator.

It seems that either A) there should exist a global authentication function that is available to all realms and it should be defined once, or B) there should be a custom authenticator function for each realm, and I should be able to define that function’s name at the realm level.

As it is, definition of the authentication function name is global (defined by the transport), but invocation is realm-based (authentication function is defined by a client/connection/session connected in the realm).

I am finding that realms are difficult to work with in relation to transports. Maybe there is a way to improve this in a future version of Crossbar?

– Dante

···

On Friday, January 16, 2015 at 3:27:49 PM UTC+4, Alexander Gödde wrote:

Regards,

Alex

Am Freitag, 16. Januar 2015 07:16:10 UTC+1 schrieb Dante Lorenso:

For my transport, I have identified a custom authenticator like:

“ws” : {

  "type" : "websocket",
  "auth" : {
  	"wampcra" : {
  		"type" : "dynamic",
  		"authenticator" : "com.domain.session.authenticate"
  	}
  }
},

In order for this authenticator to exist, I have created a client that defines this RPC call. However, the client that defines the call needs to connect to the Crossbar router using a different transport that has static authentication assigned. Upon connecting to the other transport, I need to provide the “realm” to connect to.

Suddenly, the custom authenticator only exist on that realm!

Now, when I connect to a different realm, I get an error like this:

WebSocket transport receive [3,{“message”:“no procedure ‘com.domain.session.authenticate’ registered”},“wamp.error.no_such_procedure”]

I guess that means I need to define this custom authentication method inside each realm? Meaning I need to create multiple backend clients (one for each realm)? Can’t the authenticator client connect to “all realms” for purpose of defining the same function across all realms?

– Dante

0 Likes

#4

Hi Dante,

there is indeed a 1-to-1 relationship in that each session can only be connected to one realm.

To use a single authenticator component for multiple realms, you can create several sessions, each to one of the realms you wish to cover, and then register the authenticator method for each. There’s no need to have multiple clients - a single client is not limited to a single WAMP connection/session!

Alex,

I understand what you are saying, but I do not think this is optimal design. There must be something more that can be done about this. If you are thinking modularly, ideally, you would create an authentication function just once and plug that into the router. The authentication function would support an infinite number of realms as the ‘global’ authenticator function.

Alternatively, if there is no such concept as a global authenticator function, then it should be possible to define a realm-specific authenticator function. As it is now, the “authenticator” name I define in the transport will be the same name used in all realms and unfortunately, I am now forced to build a separate connection/session for each realm the router serves. (note: I do like your suggestion to multiply the connection/session inside the same client vs creating multiple clients, and though this is better than what I was thinking, it’s still not ideal).

If the router services 10 realms, the authenticator must be modified to connect to each realm separately in order to offer the same function to each realm. This certainly doesn’t scale as realm count expands, and worse, all realm names must be manually added to this authenticator.

It seems that either A) there should exist a global authentication function that is available to all realms and it should be defined once, or B) there should be a custom authenticator function for each realm, and I should be able to define that function’s name at the realm level.

As it is, definition of the authentication function name is global (defined by the transport), but invocation is realm-based (authentication function is defined by a client/connection/session connected in the realm).

Oh, and think about this …

Create a scenario where realm1 uses authentication, but realm2 does not use authentication (both are accessed from public “front-end”).

The only way to achieve this would be to create a new transport!? Unfortunately, transports do not appear to be bound to a realm, so now all realms on transport1 require authentication and all realms on transport2 do not require authentication. Apparently we can not configure the scenario?

Is what I’m saying here true? How can you implement this scenario? AKA a) define authorization at the realm or b) bind a realm to a transport.

– Dante

···

On Friday, January 16, 2015 at 3:53:59 PM UTC+4, Dante Lorenso wrote:

On Friday, January 16, 2015 at 3:27:49 PM UTC+4, Alexander Gödde wrote:

0 Likes