How to pass information necessary for Authorization?

[flosell]

Hi, 

I'm trying to use coweb as part of a larger application which already has a working authentication mechanism.

Now I'm trying to control access to coweb resources so that users are only able to access information they are allowed to have. 

I already found methods such as SessionModerator.canClientJoinSession() that I guess would do the job. (Am I correct so far?)

Now to implement this method, I somehow need to map this call to the actual user. 

The attributes in ServerSession parameter already contain a field "username", but it's always set to "anonymous". Can I use that?

Otherwise, can I add my own data (e.g. an access-token) to the message via the JavaScript API? 

Thanks for the help, 

Florian 

[Chris Cotter]

You are correct that methods like canClientJoinSession() are intended to determine whether a client can join a session, etc.

Unfortunately, it doesn't look like the OCW API provides any way to send user-specific tokens. It could be possible to send user-specific tokens (or whatever else you want) by changing the internal OCW JavaScript code, but this is clearly undesirable for application developers.

Your best bet is to use the ServerSession's username attribute. The username is the HTTP authenticated client username. Thus, in order for this to be non-null, you will need to configure the Java web application to require HTTP authentication. Then, you can use canClientJoinSession to check the authenticated username.

The HTTP authentication method is currently the only supported mechanism in OCW. However, your question(s) bring up some interesting points.

1. CowebSecurityPolicy and Moderator overlap - both of these mechanisms effectively provide the same functionality. The primary way to check if a user can join a session/post to a service bot is checking the HTTP authenticated username. It may be desirable to remove the CowebSecurityPolicy and focus only on using the Moderator to provide the canClientJoinSession et al. callbacks. I've created an issue on GitHub for this.

2. The username is the only semantically relevant information that canClientJoinSession et al. can use to base their decisions. It may be desirable for this family of callbacks to accept an additional parameter that is arbitrary application specific data. JavaScript methods like SessionInterface.join() and CollabInterface.subscribeService() could take an additional JSON-encodable JavaScript object that gets passed to the moderator callbacks. Through such a mechanism, you could pass along application specific authentication tokens as you mentioned above.

I've created an issue for this.

3. In general, the exposed moderator API relies on the cometd implementation of the Bayeux protocol. You experienced this with using the ServerSession to get the username attribute. In general, it is undesirable for APIs to rely on internal implementation details (in this case, cometd). The moderator API should instead provide high-level parameters (username string instead of ServerSession or Message object). I created an issue for this as well.

The current development effort is to bring the OCW Python server up to date, so these issues may not be addresses immediately, but they are important considerations (especially 2 and 3).

Let us know if you have any other questions.

Chris