would like to change 'authid' inside custom authenticator

#1

In crossbar, I’d like to do WampCRA authentication but change the ‘authid’ string into a backend account_id integer value. Can the presented authid be changed so that backend tracks and stores the real account_id integer instead of the username?

– Dante

0 Likes

#2

Yes, http://crossbar.io/docs/WAMP-CRA-Authentication/ mentions optional attributes that may be returned from a dynamic authenticator with WAMP-CRA

I've added this variant to the example here:

https://github.com/crossbario/crossbarexamples/blob/master/authenticate/wampcradynamic/python/authenticator.py#L44

···

Am 03.03.2015 um 05:43 schrieb Dante Lorenso:

In crossbar, I'd like to do WampCRA authentication but change the
'authid' string into a backend account_id integer value. Can the
presented authid be changed so that backend tracks and stores the real
account_id integer instead of the username?

0 Likes

#3

Awesome. We updated to 0.10.2 and I was able to change the authid inside the authentication method.

Here is what we are doing now … We pass in a username as “authid” to the com.example.authenticate procedure and inside that procedure, we look up the account_id and password for that username. Then, we return the password as “secret”, the account_id as “authid”, and the role as “frontend”.

Now, all rpc calls can send authid === account_id to the backend modules in the disclose_me=true part of details. We can then use the true account_id for fine-grained ACL control within the backend procedure.

– Dante

···

On Thursday, March 5, 2015 at 4:56:54 AM UTC-6, Tobias Oberstein wrote:

Am 03.03.2015 um 05:43 schrieb Dante Lorenso:

In crossbar, I’d like to do WampCRA authentication but change the

‘authid’ string into a backend account_id integer value. Can the

presented authid be changed so that backend tracks and stores the real

account_id integer instead of the username?

Yes, http://crossbar.io/docs/WAMP-CRA-Authentication/ mentions optional
attributes that may be returned from a dynamic authenticator with WAMP-CRA

I’ve added this variant to the example here:

https://github.com/crossbario/crossbarexamples/blob/master/authenticate/wampcradynamic/python/authenticator.py#L44

0 Likes

#4

Unfortunately, something just “broke” when we upgraded to 0.10.3. We no longer receive the “authid” in the details struct. Now, we only see [68,2055930817,665492626,{“caller”:1204790049}]. This is not good. What happened in recent Crossbar changes?

– Dante

0 Likes

#5

Nothing changed for dynamic authenticator: this can return a dictionary (instead of simply a role), that contains an “authid”, which will then be used by Crossbar.io.

What did change is: previously, Crossbar.io forwarded all the info available from a caller (like authid, but also transport level information etc) on each call to the callee.

This is a big waste of bandwidth and cycles.

What is forwarded upon caller (and publisher) disclosure now is only the WAMP session ID of the caller (or publisher).

The detail information itself (authid etc) is available via WAMP meta API (wamp.session.get) - This allows the using code to just retrieve the info from Crossbar.io, and if desired, cache it. The info now doesn’t need to travel with each and every call (or event).

···

Am Mittwoch, 25. März 2015 16:33:31 UTC+1 schrieb Dante Lorenso:

– Dante

Unfortunately, something just “broke” when we upgraded to 0.10.3. We no longer receive the “authid” in the details struct. Now, we only see [68,2055930817,665492626,{“caller”:1204790049}]. This is not good. What happened in recent Crossbar changes?

0 Likes

#6

Do you have an advice on the practical details of a caching layer for the session information?

For example, would the cache need to subscribe to “wamp.session.on_leave” to expire session meta in the cache?

Is it at all possible for the session meta to change thus requiring a refresh?

Things like that.

Is it fair to say that if you are doing advanced access checks in the resource end-point itself, the role of a dynamic authenticator becomes somewhat redundant? It would be overkill to use the authoriser to do a broad check, and then have a more detailed check on the resource itself, no? That would be 2 separate calls, so I might as well just completely drop the authenticator and just do custom end-point access controls after getting the session information. Does that sound right?

Thanks in advance.

Regards,

Andrew Eddie

···

On Tuesday, 31 March 2015 00:29:44 UTC+10, Tobias Oberstein wrote:

The detail information itself (authid etc) is available via WAMP meta API (wamp.session.get) - This allows the using code to just retrieve the info from Crossbar.io, and if desired, cache it.

0 Likes