GB2543857A - Authorisation system - Google Patents

Authorisation system Download PDF

Info

Publication number
GB2543857A
GB2543857A GB1519367.5A GB201519367A GB2543857A GB 2543857 A GB2543857 A GB 2543857A GB 201519367 A GB201519367 A GB 201519367A GB 2543857 A GB2543857 A GB 2543857A
Authority
GB
United Kingdom
Prior art keywords
bit mask
permissions
user
action
mask
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
GB1519367.5A
Other versions
GB201519367D0 (en
GB2543857B (en
Inventor
Jones Ian
Macdonald Julie
Ronney Helen
Collins Steven
Puplett Luke
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mgm Advantage Services Ltd
Original Assignee
Mgm Advantage Services Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mgm Advantage Services Ltd filed Critical Mgm Advantage Services Ltd
Priority to GB1519367.5A priority Critical patent/GB2543857B/en
Publication of GB201519367D0 publication Critical patent/GB201519367D0/en
Publication of GB2543857A publication Critical patent/GB2543857A/en
Application granted granted Critical
Publication of GB2543857B publication Critical patent/GB2543857B/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • G06F21/335User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00Individual registration on entry or exit
    • G07C9/20Individual registration on entry or exit involving the use of a pass
    • G07C9/27Individual registration on entry or exit involving the use of a pass with central registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C2209/00Indexing scheme relating to groups G07C9/00 - G07C9/38
    • G07C2209/04Access control involving a hierarchy in access rights
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00Individual registration on entry or exit
    • G07C9/30Individual registration on entry or exit not involving the use of a pass
    • G07C9/38Individual registration on entry or exit not involving the use of a pass with central registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

A method of authorising a user comprises combining a user bit mask and a permissions bit mask, the user bit mask corresponding to permissions granted to the user and the permissions bit mask defining permissions requirements for an action, and determining, on the basis of the combination, whether the user is authorised for an action. The permissions bit mask may be one of a positive (allow) bit mask, a negative (deny) bit mask, or a mandatory bit mask. The combining may use an AND operation or an XOR operation. The user bit mask may be combined with several different types of permissions bit masks. The user action may be to invoke an Application Program Interface (API), or to view data or write data. The user bit mask may be received in the form of an encrypted token.

Description

Authorisation system
Field of invention
This invention relates to an authorisation system, apparatus and method; and more particularly relating to controlling access to systems, locations and/or resources.
Background
With the increasing use of online services, maintaining authorisation of various users of the system in question is an increasing concern. This problem is particularly acute where different levels of authorisation are granted for different users, and where these different authorisation levels correspond to the ability to access certain resources, access particular locations, or perform certain actions.
Access to functionality may be controlled through an authorisation system. Each user of the online service may be enabled to perform certain tasks, receive certain data, or use certain functionality.
Examples of permissions include the ability for a user to: • Access a particular area within a building • Control an external system (e.g. commence / halt operation of an industrial process) • Override default data • Pick up / amend incomplete actions • View data • Delete data • Modify other user’s data ‘Roles’ are created to organise and manage permissions so that they can be applied at a broader level to the user accounts in the system. For example a ‘manager’ may be permitted to perform all of the above tasks, but a ‘trainee’ may only be permitted to view data. A problem with this approach is that an administrator needs to be aware (and kept aware) of how the system works to set the correct permissions for a user's role. This would require technical knowledge of the system and the ability to re-code if necessary.
The use of ‘roles’ as described above creates an intrinsically complex and inflexible system.
An improved solution is therefore desired.
According to one aspect, there is provided a method of authorising a user, comprising: combining a user bit mask and a permissions bit mask; the user bit mask corresponding to permissions granted to the user and the permissions bit mask defining permissions requirements for an action, thereby to generate a combination of the user bit mask and the permissions bit mask; and determining, on the basis of said combination, whether the user is authorised for an action. This method provides a simple and efficient manner in which to authorise a user.
For ease of denying authorisation, the permissions bit mask may comprise an element corresponding to a negative permission. The method may comprise denying access for the action if a bit corresponding to a negative permission is set in said combination.
For ease of granting authorisation, the permissions bit mask may comprise an element corresponding to a positive permission. The method may comprise permitting access for the action if a bit corresponding to a positive permission is set in said combination.
For ease of specifying mandatory permissions, the permissions bit mask may comprise an element corresponding to a mandatory permission. The method may comprise permitting access for the action if said combination is the same as said permissions bit mask.
For computational efficiency and speed, the combining step may use a bit-wise AND operation.
For computational efficiency and speed, the method may further comprise combining said combination and said mandatory permissions bit mask using an XOR operation.
For additional authorisation checks, the method may further comprise combining the user bit mask with a further permissions bit mask; said further permissions bit mask preferably corresponding to a different type of permission to said permissions bit mask.
The permissions bit mask or said further permissions bit mask may be one of a negative bit mask, a mandatory bit mask, and a positive bit mask. Thereby providing a flexible authorisation system and method.
So as to reduce potentially unnecessary calculations, a negative permissions bit mask is combined with the user bit mask prior to a positive permissions bit mask.
So as to reduce potentially unnecessary calculations, a mandatory permissions bit mask is combined with the user bit mask prior to a positive permissions bit mask.
So as to reduce potentially unnecessary calculations, a negative permissions bit mask is combined with the user bit mask prior to a mandatory permissions bit mask.
The method may further comprise providing access to a further system so as to permit access to that further system. Said further system may comprise a resource provision system.
So as to permit authorised users to access to an API, the action may be to invoke an Application Program Interface (API).
So as to only permit authorised users to view data, said action may be to view data.
So as to only permit authorised users to write data, said action may be to write data.
The method may comprise receiving the user bit mask.
For ease and/or security of transmission, the user bit mask may be in the form of an encrypted token. For security, the method may further comprise decrypting the token and retrieving the user bit mask.
For the convenience of an authorised user, the method may further comprise generating a session token indicating the authorisations of the user.
So as to enable continued authorised access, said token may be attached to subsequent authorisation requests.
According to another aspect there is provided a computer program product operable to carry out the method as described herein.
According to another aspect, there is provided an apparatus for authorising a user, comprising: means (preferably in the form of a processor and a suitably programmed memory) for combining a user bit mask with a permissions bit mask, the user bit mask corresponding to permissions granted to the user, the permissions bit mask defining permissions requirements for an action; and means (preferably in the form of a processor an d a suitably programmed memory) for determining, on the basis of said combination, whether the user is authorised for an action.
The invention extends to any novel aspects or features described and/or illustrated herein.
Further features of the invention are characterised by the other independent and dependent claims
Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.
Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.
Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.
It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.
The invention also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps.
The invention also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.
The invention also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
The invention also provides a computer readable medium having stored thereon the computer program as aforesaid.
The invention also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.
The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.
The invention will now be described by way of example, with references to the accompanying drawings in which:
Figure 1(a) shows an example authorisation process involving two permissions bit masks;
Figure 1(b) shows an example authorisation process involving three permissions bit masks;
Figure 2(a) shows an application of an authorisation system in a resource provision system;
Figure 2(b) shows an application of an authorisation system in a building access system; Figure 3 shows an example authorisation system; and Figure 4 shows a single sign-on process.
Detailed description
Permissions System
The present system is operable to manage fine-grained permissions in a manner which is simple to adjust. By focussing on permissions, new roles can be created or edited by non-technical administrators without code changes and without significant impact on the operation of the wider system thereby providing a simple, scalable and efficient permissions system.
In overview, a permissions ‘bit mask’ is created, the bit mask comprising a number of different elements corresponding to different specific permissions. This mask is then combined with a mask corresponding to permissions granted to a user. It is then determined whether the user is authorised based on the combination of the two masks.
Such a method allows flexibility as permissions can be easily added or deleted by modifying bits in either the user’s mask or the permission mask. Combining bit masks can be performed in a bit-wise fashion which is fast and efficient compared to using look-up tables (for example).
In this document, the term ‘user’ preferably refers to an individual, a group of individuals, a third party authorised to act on behalf of an individual or group of individuals, or a customer services representative working for the service provider. It may also refer to the owner of a pass card or similar device which authorises an individual or group of individuals.
Applications of a permissions system include a system for managing access to areas of a building, or a user accessing resources provided by various different systems. It should be appreciated that numerous other applications exist, but the present description will focus on these examples.
Binary Permissions
Each individual permission is allocated a binary bit flag, a single bit set at an offset, stored in the database as a byte array in a binary column.
The following example is for a customer service department trainee Role:
As can be seen, the ‘bit mask’ is created by bitwise AND of all the permissions. The permissions labelled ‘A’ are ‘positive’ permissions, whereas the permissions labelled ‘F are ‘negative’ permissions. Bit-wise operations are very simple and efficient to perform; one example of a process able to read a byte array and perform bit-wise operations is ‘C# Biglnteger’.
The permission label may be defined by a ‘bit offset’; the bit that is set is determined by its position in the bit array. For example, the permission A3 may be represented as ‘offset index 3’ (counting from the right hand side). A member of the customer service department trainee Role has 00100111 as her permissions in binary form, i.e. the coalesced AND binary product of all bit flags on all her permissions.
An example API controller action has the following permission requirements: [Permission(Permissionld = "A2", Access.Grant)] // 00000010 [Permission(Permissionld = "A3", Access.Grant)] // 00000100 [Permission(Pemnissionld = "F5", Access.Deny)] // 00100000 public HttpResponseMessage PutCustomer(string id) {}
This controller action thus has two bit masks, one for ‘Access Grant’ (a positive permissions bit mask) and another for ‘Access Deny’ (a negative permissions bit mask). Each mask is the coalesced binary from all permissions of the same grant type, as a single AND result.
In the example shown, there is only one ‘Access.Deny’ permission; the deny mask requires no further calculation, but, for ‘Access.Grant’ permissions, (00000010 AND 00000100) produces 00000110:
Deny mask 00100000
Allow mask 00000110
Therefore, in order to determine whether the user has permission for the requested action (e.g. invoke a specific API or open a door), first, the deny mask (if present) is combined with her bit mask. If any bits are still set, then she is denied access and no further processing is undertaken.
Deny mask 00100000 Sarah's mask 00100111 AND 00100000
Access is denied to the user. Access is denied to anyone in that role, in fact, because all those role members with have ‘deny’ permission F5. A second user, Jake, without the F5 permission, would have continued to run through the following logic:
Grant mask 00000110 Jake's mask 00000111 AND 00000110
Since the above is a grant check and the AND result contains at least a single bit set, then the access is granted for Jake, that is to say, Jake has at least one of the permissions required to carry out the requested action (for example, invoke an API or open a door).
This process is illustrated by Figure 1(a), indicating the order in which the masks are applied. A ‘deny bit mask’ 100 is combined with a ‘user bit mask’ 102 in an AND junction 104. The result is then checked to determine whether the result is zero (i.e. full of unset bits).
It should be noted that if a certain permission or set of permissions are mandatory (as opposed to having at least one of the permissions present in the ‘allow mask’), a further mask may be used, termed a ‘mandatory mask’. Such a mask is effectively the inverse of the ‘deny mask’ - all the bits set in the ‘mandatory mask’ must also be set in the user’s mask. The example below illustrates such a scenario:
Mandatory mask: 11000000 David’s mask: 11100111 AND: 11000000
This result is then stored and compared to the mandatory mask, for example by way of an XOR operation. If the result is the same as the mask (in the case of an XOR operation, every bit being zero), the user has the required permissions. AND result: 11000000 Mandatory mask: 11000000 XOR: 00000000
David thus has the required permissions and the process may continue.
The order of mask-checking is advantageously as follows: 1. Deny mask (negative permissions) 2. Mandatory mask (mandatory permissions) 3. Grant mask (positive permissions)
This order is advantageous as the subsequent mask need only be checked if the previous checks were passed, thus avoiding potentially unnecessary calculations.
Bitwise calculations are very processor efficient, and calculations can occur very quickly leading to lower latency in accessing (or being denied to) the requested service or action compared to other methods (such as database lookup methods).
The staged process of calculating the ‘deny’ output first means that if a user is specifically denied from a certain action, their positive permissions are not considered, resulting in fewer bitwise operations, further increasing the speed and efficiency of the authorisation process.
It should be appreciated that not all scenarios would have all types of mask; in particular a mandatory mask may not be used.
Figures 2(a) and 2(b) show particular applications of the above authorisation system.
Figure 2(a) shows the application of an authorisation system in a resource provision environment. A user 10 attempts to access a particular resource, provided by a resource provider 14. An authorisation server 12 receives the user permission bit mask and combines it with the permissions bit mask for the relevant resource provider 14. If the authorisation server 12 determines that the user 10 is authorised, the requested resource is then provided to the user 10.
Figure 2(b) shows the application of an authorisation system in a building access control environment. A user 10 with a pass may attempt to access certain areas 14 of a building. In one example the user’s pass contains an RFID (Radio-Frequency Identification) chip which is readable by a RFID reader at the door of each area 14. The reader at the area 14 that the user is attempting to gain access to passes the user’s bit permissions to an authorisation server 12 which combines it with the permissions bit mask corresponding to the relevant area 14. If the authorisation server 12 determines that the user 10 is authorised, the door to the relevant area 14 is unlocked thereby allowing the user 10 to access that area 14. The user pass may be contained within a mobile telephone with suitable hardware and software, for example utilising NFC (Near-Field Communication).
The Authentication Token
In use, an authentication token is produced and passed to the authenticating party (for example, the authorisation server 12) for inspection. The token may be encrypted so that it cannot easily be tampered with by the user, and prevents a third party from creating their own token. The following description shows an example method of token creation and subsequent use.
An authorisation token is prepared using the complete set of permissions from all Roles she has. The resulting bit mask is converted into a base-64 encoded byte array and written to an authentication token, before it is signed and encrypted and base-64 encoded again. { "Personl D": "abc123", User identifier "Expires": "2015-05-19T07:22Z", Expiry date for token "PermissionMask": 241, 241 = 11110001 "HMAC", Keyed-Hash Message Authentication Code "fbdbldl b18aa6c08324b7d64b71 fb76370 690e1d" }
The token is passed to an application where it may be attached as the following HTTP header:
Authorization: Bearer {base-64 encoded token string}
The Web API comprises middleware (such as Open Web Interface for .NET (OWIN) middleware) that inspects the headers coming in on each request and looks for the ‘Authorization’ header. It then decodes, decrypts, verifies the signature and decodes the permissions (241 = 11110001).
The authorisation token may be generated when a user attempts to log on (e.g. in the system of Figure 2(a)), or may be embedded in a user access pass for use in an access control system (such as the system shown in Figure 2(b)).
Once the system is satisfied the user is authorised, it may look-up the user so as to provide the service and/or undertake the requested action.
User Interface Permissions
The functionality in a front-end application depends upon permissions assigned to roles.
The user interface (Ul) may, for example, hide options or grey out various Ul controls based upon the user's permissions. Once in possession of a valid token, a user may able to call the API to retrieve a list of permissions in effect for the token so as to determine which actions they are able to perform.
The token itself cannot be decrypted by the user, prohibiting direct evaluation of the permissions and the structure of the bit masks. The use of the token as described above means that the same token can be utilised for a number of different front-end applications.
Authenticating an API client: Flowing Tokens
The following description with reference to Figure 2 outlines an example process for authenticating a user of an API client. In the example below, the API is an AngularJS single-paged application framework - within a Web API.
In overview, the process ensures that the user is able to perform the actions that they are permitted to, and not those they are not permitted to. 1. A user sends a message requesting access to the service provider’s Web API. This may be via by POSTing an XML message to a specific URL. The URL contains the name of the Security Assertion Markup Language (SAML) provider and the (SAML) response, encoded in base-64. A Web API controller action handles the request. The message may contain a nonce so as to avoid replay attacks by third party eavesdroppers. 2. The nonce (if present) is checked against a cache of previously seen messages and if not seen before, its own nonce is cached. 3. The API server uses the unique identifier for the user in the message to locate the linked web user account in the front-end database and verifies their account is active. 4. The API server creates an authorization grant code and writes this code to a shared storage database and responds with an HTTP redirect to the appropriate Single Page Application (SPA) landing page for the web user. The authorization code is embedded in the URL. 5. The API client processes the URL to extract the authorization code (e.g. by GETting the URL in the redirection response). If the client is a web browser, then the redirection will be dereferenced and the SPA page and JavaScript will load. The SPA code can then extract the authorization code.
If the user is acting for another user, the following three steps may be performed: 6. The API client calls an "Authorised Act-as Parties" endpoint, supplying the authorization code, and receives a list of users that the web user can act as. This endpoint is open to all callers but needs a valid authorization code. This additional API call thereby supplies the authentication code to prove that the user is in fact authorised to act for other users. 7. A list of IDs of the users the user is allowed to act as is returned The API client can present this list to the user for selection. For web users who do not have the ability to act for others, this list will be populated by only the web user themselves, or may be empty. 8. The selected ID is supplied to the API to obtain an access token (as described above). The API client makes a call to the "Access Token" endpoint, supplying the chosen party ID as a query parameter named "scope". 9. The API server validates the authorization token, locates the web user using it, verifies the scope is valid against the authorized list of act-as parties, and then makes a check against a business integration server to ensure that, if applicable, the relationship between users is still intact and all accounts are valid. Finally, a token is generated encapsulating the web user ID, the act-as party ID, permission bits and a Hashed Message Authentication Code (HMAC), which is encrypted and returned along with a refresh token, which is stored against their session. 10. The API client stores the token and attaches it in all subsequent API calls as the Authorization HTTP header. 11. The API client refreshes the token before its expiry date by calling the "Access Token" endpoint supplying a grant_type query parameter as "refresh_token" and the "refresh_token" parameter as the token value. 12. The API server confirms the refresh token in session state and mints a new access token, performing the same checks as before so that an account termination in the business integration server takes effect for running clients in a timely manner.
The SPA, web API, database, front end database and business integration server shown in Figure 2(b) may be contained within a single organisation (or indeed, in single server), or may be over different organisations and physical locations. Furthermore, the individual elements identified may be further split up, for example into different modules or servers adapted for a specific role.
Tokens and Security within Web API
When the Web API handles a request for a resource, it is necessary for the API to be able to determine the identity and authorization of the caller.
It is important to remember that certain users may be acting for another user, not themselves, so they have a ‘dual identity’.
The access token may comprise the following information: - The web user account identifier, which may comprise a GUID. - An identifier to represent a scope, context or other agent being impersonated or acting on behalf of. - A (base-64) encoded byte array of the binary bit flags for the web user's permissions. - A cryptographic signature of the values in the token for tamper detection.
The access token may contain the state and pass it along with each request, or the token may be merely a key used to look-up the state about the session.
Single Sian-On
Figure 3 illustrates a method of a user signing in to a web-based service provider utilising a single sign-on provider. The flow begins when the user lands at a ‘Login with single sign-on’ page. 1. The browser on the user device 300 GETs the ‘Login with Single Sign-on’ page. 2. The service provider 302 responds with a payload containing an HTML form element and script to POST a SAML ‘AuthnRequest’ XML message to the Single Sign-on Identity Provider (IDP) 304. 3. The browser 300 submits the form and POSTs the XML message to the Single Sign-on IDP 304. The message identifies the Service Provider 302 but not the user. It is signed using the service provider certificate. The user then signs-in at the single sign on page. 4. The single sign-on IDP 304 returns an HTML form element and script to the browser 300 to POST a response XML message back to the service provider website. 5. The response is POSTed and the service provider 302 determines if the request should be denied or granted.
The service provider website is ‘stateless’, only becoming aware that a user has logged in upon the receipt of the POSTed SAML response message. From that point, a ‘model-view-control’ (MVC) website can take whatever action necessary, such as redirect to a SPA URL with a token in the URL.
In such a way, the authorisation of a user’s session is determined by the service provider 302 as opposed to the single sign-on provider 304 which only needs to be accessed once.
The token-flow method described above ameliorates a potential problem where a single sign-on is used. If separate sessions were created for the single sign-on provider and the resource authorisation provider, there is a possible conflict in the sessions timing out and/or becoming invalid at different times. This may result in loss of functionality or require a user to enter their sign-on details again. The use of a single token flowing between the various elements of the system means that there is a single element which determines when a session would time out. Furthermore, this token can be refreshed in the background without requiring the user to re-enter their single sign-on details.
Alternatives and modifications
Various other modifications will be apparent to those skilled in the art for example permissions may correspond to more than one bit in the bit masks. The bit masks have been described as being binary form, but any base may be used if considered appropriate, in particular when transmitting or encrypting the permissions masks.
The above description describes the permissions defined as binary bits that are set; alternatively the inverse could be the case, where the permissions set correspond to unset binary bits. In such a case, the AND gates used could be replaced by NAND gates and the subsequent analysis adjusted accordingly.
It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.
Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims (30)

Claims
1. A method of authorising a user, comprising: combining a user bit mask and a permissions bit mask; the user bit mask corresponding to permissions granted to the user and the permissions bit mask defining permissions requirements for an action, thereby to generate a combination of the user bit mask and the permissions bit mask; and determining, on the basis of said combination, whether the user is authorised for an action.
2. A method according to claim 1 wherein the permissions bit mask comprises an element corresponding to a negative permission.
3. A method according to claim 2 comprising denying access for the action if a bit corresponding to a negative permission is set in said combination.
4. A method according to claim 1 wherein the permissions bit mask comprises an element corresponding to a positive permission.
5. A method according to claim 4 comprising permitting access for the action if a bit corresponding to a positive permission is set in said combination.
6. A method according to claim 1 wherein the permissions bit mask comprises an element corresponding to a mandatory permission.
7. A method according to claim 6 comprising permitting access for the action if said combination is the same as said permissions bit mask.
8. A method according to any preceding claim wherein the combining step uses a bit-wise AND operation.
9. A method according to claim 7 further comprising combining said combination and said permissions bit mask using an XOR operation.
10. A method according to any preceding claim further comprising combining the user bit mask with a further permissions bit mask.
11. A method according to claim 10 wherein said further permissions bit mask corresponds to a different type of permission to said permissions bit mask.
12. A method according to claim 11 wherein said permissions bit mask or said further permissions bit mask is one of a negative bit mask, a mandatory bit mask, and a positive bit mask.
13. A method according to claim 12 wherein a negative permissions bit mask is combined with the user bit mask prior to a positive permissions bit mask.
14. A method according to claim 12 or 13 wherein a mandatory permissions bit mask is combined with the user bit mask prior to a positive permissions bit mask.
15. A method according to any of claims 12 to 14 wherein a negative permissions bit mask is combined with the user bit mask prior to a mandatory permissions bit mask.
16. A method according to any preceding claim further comprising providing access to a further system.
17. A method according to claim 16 wherein said further system comprises a resource provision system.
18. A method according to any preceding claim wherein said action is to invoke an Application Program Interface (API).
19. A method according to any preceding claim wherein said action is to viewdata.
20. A method according to any preceding claim wherein said action is to write data.
21. A method according to any preceding claim comprising receiving the user bit mask.
22. A method according to claim 21 wherein the user bit mask is in the form of an encrypted token.
23. A method according to claim 22 further comprising decrypting the token and retrieving the user bit mask.
24. A method according to any preceding claim further comprising generating a session token indicating the authorisations of the user.
25. A method according to claim 24 wherein said token is attached to subsequent authorisation requests.
26. A computer program product operable to carry out the method of any preceding claim.
27. An apparatus for authorising a user, comprising: means (preferably in the form of a processor and a suitably programmed memory) for combining a user bit mask with a permissions bit mask, the user bit mask corresponding to permissions granted to the user, the permissions bit mask defining permissions requirements for an action; and means (preferably in the form of a processor and a suitably programmed memory) for determining, on the basis of said combination, whether the user is authorised for an action.
28. A method substantially as herein described with reference to the accompanying drawings.
29. A computer program product substantially as herein described with reference to the accompanying drawings.
30. An apparatus substantially as herein described with reference to the accompanying drawings.
GB1519367.5A 2015-11-02 2015-11-02 Authorisation system Expired - Fee Related GB2543857B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB1519367.5A GB2543857B (en) 2015-11-02 2015-11-02 Authorisation system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1519367.5A GB2543857B (en) 2015-11-02 2015-11-02 Authorisation system

Publications (3)

Publication Number Publication Date
GB201519367D0 GB201519367D0 (en) 2015-12-16
GB2543857A true GB2543857A (en) 2017-05-03
GB2543857B GB2543857B (en) 2018-04-04

Family

ID=55130570

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1519367.5A Expired - Fee Related GB2543857B (en) 2015-11-02 2015-11-02 Authorisation system

Country Status (1)

Country Link
GB (1) GB2543857B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT202100025925A1 (en) * 2021-10-08 2023-04-08 Phoenix ICT ANTI DDOS METHOD AND SYSTEM FOR THE DYNAMIC MANAGEMENT OF AN ACTIVE RESOURCE

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220405571A1 (en) * 2021-06-16 2022-12-22 Microsoft Technology Licensing, Llc Sparsifying narrow data formats for neural networks

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0398645A2 (en) * 1989-05-15 1990-11-22 International Business Machines Corporation System for controlling access privileges
US20050210263A1 (en) * 2001-04-25 2005-09-22 Levas Robert G Electronic form routing and data capture system and method
EP1626372A1 (en) * 2004-08-11 2006-02-15 Swisscom AG Access control method, access control system and devices therefor
US20060047689A1 (en) * 2004-09-02 2006-03-02 Microsoft Corporation Centralized terminology and glossary development
WO2009076755A1 (en) * 2007-12-17 2009-06-25 Ramius Corporation Social networking site and system
US7702693B1 (en) * 2003-10-30 2010-04-20 Cisco Technology, Inc. Role-based access control enforced by filesystem of an operating system
US20140325640A1 (en) * 2013-04-30 2014-10-30 Netapp, Inc. Secure access-based enumeration of a junction or mount point on a clustered server

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0398645A2 (en) * 1989-05-15 1990-11-22 International Business Machines Corporation System for controlling access privileges
US20050210263A1 (en) * 2001-04-25 2005-09-22 Levas Robert G Electronic form routing and data capture system and method
US7702693B1 (en) * 2003-10-30 2010-04-20 Cisco Technology, Inc. Role-based access control enforced by filesystem of an operating system
EP1626372A1 (en) * 2004-08-11 2006-02-15 Swisscom AG Access control method, access control system and devices therefor
US20060047689A1 (en) * 2004-09-02 2006-03-02 Microsoft Corporation Centralized terminology and glossary development
WO2009076755A1 (en) * 2007-12-17 2009-06-25 Ramius Corporation Social networking site and system
US20140325640A1 (en) * 2013-04-30 2014-10-30 Netapp, Inc. Secure access-based enumeration of a junction or mount point on a clustered server

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT202100025925A1 (en) * 2021-10-08 2023-04-08 Phoenix ICT ANTI DDOS METHOD AND SYSTEM FOR THE DYNAMIC MANAGEMENT OF AN ACTIVE RESOURCE

Also Published As

Publication number Publication date
GB201519367D0 (en) 2015-12-16
GB2543857B (en) 2018-04-04

Similar Documents

Publication Publication Date Title
EP3704621B1 (en) Secure identity and profiling system
US10270741B2 (en) Personal authentication and access
US10055561B2 (en) Identity risk score generation and implementation
US11122035B2 (en) Secure delegation of a refresh token for long-running operations
US10484385B2 (en) Accessing an application through application clients and web browsers
US9300653B1 (en) Delivery of authentication information to a RESTful service using token validation scheme
KR101486613B1 (en) Transferable restricted security tokens
EP2529527B1 (en) Method for controlling access to resources
US11277267B2 (en) Fine-grained token based access control
US8151317B2 (en) Method and system for policy-based initiation of federation management
US20120110469A1 (en) Systems and Methods for Cross Domain Personalization
EP2936768A1 (en) A system and method of dynamic issuance of privacy preserving credentials
Kubovy et al. A secure token-based communication for authentication and authorization servers
GB2543857A (en) Authorisation system
Chadwick et al. My private cloud–granting federated access to cloud resources
Marillonnet et al. An Efficient User‐Centric Consent Management Design for Multiservices Platforms
Pöhn et al. New directions and challenges within identity and access management
US11849041B2 (en) Secure exchange of session tokens for claims-based tokens in an extensible system
Li Context-aware attribute-based techniques for data security and access control in mobile cloud environment
Sohrabi et al. Privacy of cloud data using a secure SSO architecture
CN114500031B (en) System, method, electronic equipment and medium for acquiring BI report based on single sign-on
Siriwardena et al. UMA Evolution
Alrodhan Identity management systems
Mayank et al. User-Based Authentication for Web Apps
Shetty et al. New Security Architecture for Big Data Hadoop

Legal Events

Date Code Title Description
COOA Change in applicant's name or ownership of the application

Owner name: MGM ADVANTAGE SERVICES LIMITED

Free format text: FORMER OWNER: MGM ADVANTAGE HOLDINGS LIMITED

732E Amendments to the register in respect of changes of name or changes affecting rights (sect. 32/1977)

Free format text: REGISTERED BETWEEN 20210610 AND 20210616

PCNP Patent ceased through non-payment of renewal fee

Effective date: 20221102