Authorisation framework for bot... #272

New issue

Closed

opened 2025-10-14 17:53:19 -06:00 by navan · 0 comments

navan commented

2025-10-14 17:53:19 -06:00

Owner

Originally created by @seghcder on 7/6/2017

As mentioned in #51 , Program Y assumes that if you can reach it, you can use it. In a Skype For Business enterprise context, I need to check if the user connecting -

Is a known user and is allowed to use the bot
Is permitted to use all or only some services
Is a super-user who can ask questions like who is connected to the bot right now, service online/offline commands, send a message to all connected users, or even tell the bot to quit gracefully.

For now I have only implemented point 1. Here's my approach:

Created an authorisation pre-proccessor along these lines -

if ServiceFactory.get_service("authservice").checkUserAuth(bot,clientid):
  question  = string
else:
  question = "CheckUserAuthFailed " + clientid

CheckUserAuthFailed then points to a grammar along these lines:

   <category>
        <pattern>CHECKUSERAUTHFAILED #</pattern>
        <template>Your user-id  '<star/>' failed authorisation 
                           - sorry I can't help you yet!</template>
    </category>

The authservice is just another service defined along normal Program-Y guidelines. The idea is future authorisation checks can be done via service calls or grammar.

In the authservice, I then maintain a list of currently authorised users.

self.authorisedUsers = {} 
self.authorisedUsers['CONSOLE'] = "basic"

(This assumes that someone using the CONSOLE app must have general access)

Then, when checkUserAuth is called -

if clientid.upper() not in self.authorisedUsers:
  if self._api.AuthUser(bot,clientid):
    self.authorisedUsers[clientid] = "authenticated"
    result = True

The AuthUser API does the back-end service call to actually check the user is known, for example against the ticket system or in an Active Directory. This way the user is not re-authenticated against the master every time they ask a question.

Next steps are to flesh out the role / service-level authorisation model.

If there are any thoughts / comments / ideas / problems with the above approach, please do comment :-)

*Originally created by @seghcder on 7/6/2017* As mentioned in #51 , Program Y assumes that if you can reach it, you can use it. In a Skype For Business enterprise context, I need to check if the user connecting - - Is a known user and is allowed to use the bot - Is permitted to use all or only some services - Is a super-user who can ask questions like who is connected to the bot right now, service online/offline commands, send a message to all connected users, or even tell the bot to quit gracefully. For now I have only implemented point 1. Here's my approach: Created an authorisation pre-proccessor along these lines - ``` if ServiceFactory.get_service("authservice").checkUserAuth(bot,clientid): question = string else: question = "CheckUserAuthFailed " + clientid ``` CheckUserAuthFailed then points to a grammar along these lines: ``` <category> <pattern>CHECKUSERAUTHFAILED #</pattern> <template>Your user-id '<star/>' failed authorisation - sorry I can't help you yet!</template> </category> ``` The authservice is just another service defined along normal Program-Y guidelines. The idea is future authorisation checks can be done via service calls or grammar. In the authservice, I then maintain a list of currently authorised users. ``` self.authorisedUsers = {} self.authorisedUsers['CONSOLE'] = "basic" ``` (This assumes that someone using the CONSOLE app must have general access) Then, when checkUserAuth is called - ``` if clientid.upper() not in self.authorisedUsers: if self._api.AuthUser(bot,clientid): self.authorisedUsers[clientid] = "authenticated" result = True ``` The AuthUser API does the back-end service call to actually check the user is known, for example against the ticket system or in an Active Directory. This way the user is not re-authenticated against the master every time they ask a question. Next steps are to flesh out the role / service-level authorisation model. If there are any thoughts / comments / ideas / problems with the above approach, please do comment :-)

navan closed this issue

2025-10-14 17:53:21 -06:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github/program-y#272

No description provided.

Rows
Columns