Patent ID: 12250224

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The following description of embodiments provides non-limiting representative examples referencing numerals to particularly describe features and teachings of different aspects of the invention. The embodiments described are recognized as capable of implementation separately, or in combination, with other embodiments from the description of the embodiments. A person of ordinary skill in the art reviewing the description of embodiments can learn and understand the different described aspects of the invention. The description of embodiments can facilitate understanding of the invention to such an extent that other implementations, not specifically covered but within the knowledge of a person of skill in the art having read the description of embodiments, would be understood to be consistent with an application of the invention.

The present disclosure can include systems, methods, and computer-accessible mediums for dynamic, granular user access permissions.

FIG.1is a schematic diagram of a system100for dynamic, granular user access permissions, according to an example embodiment. Access permissions for one or more users can be maintained in an access permission database102. The access permission database102can be a relational or non-relational database, or a combination of more than one database. The access permissions database102can be stored remotely, such as in another server106, on a cloud-based platform, or in any storage device that is in data communication with the user's device104. The server106storing the access permission database102can be a dedicated server computer, such as bladed servers, or can be personal computers, laptop computers, notebook computers, palm top computers, network computers, mobile devices, or any processor-controlled device capable of supporting the access permission database and communicating with the user's device. In an embodiment, access permissions can be maintained in JavaScript Object Notation (“JSON”) form and communicated as a HyperText Transfer Protocol (“HTTP”) response, data stream, JSON web token, or any suitable method to transport data from one system to another. Multiple servers or multiple computer systems can be used as necessary or desired to support the user. Back-up or redundant servers may also be used to prevent network downtime in the event of a failure of a particular server.

The user's device104can be a desktop computer, a laptop computer, a tablet computer, a smartphone, a personal digital assistant, a thin client, a fat client, a combination thereof, or any other device supporting the work the user is required to perform. The user's device104can include a processor and a memory. It is understood that the processing circuitry can contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives and tamper proofing hardware, as necessary to perform the functions described herein.

The memory can be a read-only memory, write-once, read-multiple memory or read/write memory, e.g., RAM, ROM and EEPROM, and the user's device can include one or more of these memories. A read-only memory can be factory programmable as read-only or one-time programmable. One-time programmability provides the opportunity to write once then read many times. A write once/read-multiple memory can be programmed at a point in time after the memory chip has left the factory. Once the memory is programmed, it cannot be rewritten, but it can be read many times. A read/write memory can be programmed and re-programmed many times after leaving the factory. It can also be read many times.

The user's device104can further include wired or wireless data communication capability. These capabilities can support data communication with a wired or wireless communication network, a wireless personal area network, a wide area network, any other wired or wireless network for transmitting and receiving a data signal, or any combination thereof. This network can include, without limitation, telephone lines, fiber optics, IEEE Ethernet 902.3, a wide area network, a local area network, a wireless personal area network, a wide body area network or a global network, such as the Internet. The user's device104can also support a short-range wireless communication interface, such as near field communication, radio-frequency identification, and Bluetooth.

The user's device104can further include a display and input devices. The display can be any type of device for presenting visual information such as a computer monitor, a flat panel display, and a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices can include any device for entering information into the user's device104that is available and supported by the user's device104such as a touch-screen, keyboard, mouse, cursor-control device, microphone, digital camera, video recorder or camcorder. These devices can be used to enter information and interact with the software and other devices described herein.

FIG.2is a client-server interaction diagram, according to an example embodiment. An application can be designed using an architecture that splits the application into separate client and server components that communicate over a protocol such as HTTP. Each component can have a role in securing the application. A client202can communicate with a server204for authorization. The client202can send a message206to obtain users authorized using a shared authorization model such as JSON web tokens (“JWT”) and, in response, the server204can send a message208with a status code (e.g., code200) representing whether or not the users are authorized.

Authentication can be when the user supplies some information to a system that can be validated by the system. This can include multiple checks, along with a set of credentials like a username and password. Authentication can be used to try to determine “who are you?” Authorization is also interested in who the user is, but is used to determine what functions, actions, data, or other parts of an application the user has access. Authorization answers the question “what can you do?” It's not a requirement for a user that's been authenticated to also be authorized. An unauthenticated user can have some access to an application, although usually in a very limited capacity. In short, authentication is the process of verifying that “you are who you say you are,” while authorization is the process of verifying that “you are permitted to do what you are trying to do.”

When managing user authentication and authorization between client and server, or server-to-server, one option is token-based authorization. JSON web tokens (JWT) can provide a stateless communication mechanism for authorization. JWTs are JSONs that are cryptographically signed and able to be verified and validated by the recipient.

There can be many client and server interactions as a user navigates through an application having security aspects. The server204can validate and verify requests from the client202, securing the application. For example, when the user opens the application on client202, the user can first be authorized as an unauthenticated user. For example, a login screen or an application user interface can be displayed with a limited set of functionality. Next, the user is authenticated and the server204can successfully validate that the user is who they say they are. From there, the server can generate a JWT and send it back to the client application to store. Once the client application has some information about the user, such as information from the JWT, the client application can start to enable functionality for that user. If the user continues to be active in the application, the client202can continue making and processing requests to the server204, passing the JWT to authorize each request.

A client-server system can use different approaches to authorization, such as role-based authorization (user→role→permissions), claims-based authorization (user→permission→action), or attribute-based authorization (policy>authorization→user). When role-based authorization is used, a user is assigned to a role or roles that determine what access they have within an application. This access can be to pages, components, functionality, or data within the application. A role-based approach to authorization usually aligns with an organization's hierarchy. An example group of roles can be manager, user and admin. These roles, when assigned to various users of an application, can grant some level of access to functionality and data. With role-based authorization, the client application can grant access to users based on their roles.

Another approach to authorization is claims-based authorization. Claims-based authorization can provide a more granular level of control over the authorized functionality for a user. In claims-based authorization, an application claims that a user can take actions such as editing products. Claims-based authorization can provide a level of authorization that is tied to the user and is not specific to a role within the application or organization. A claim can also be used to modify the user experience on the client application by enabling or disabling functionality for a user. As applications grow with more features and user types, roles-based and claims-based authorization approaches can become limiting. In such a scenario, an attribute-based approach can be beneficial.

An attribute-based approach to authorization is where a policy can be created to determine what authorization a user has within an application based on some condition. The policy can be anything. For example, the policy can be based on a business rule that application users are not allowed to edit product descriptions prior to 8:00 a.m. on the weekend. Another policy can be that all users in a specific security group can only view location information. Another policy can be that all users in the development environment have admin access. A set of policies can fit into a pattern for an application. Once that pattern is defined, logic can be used to make determinations about a user's access.

An attribute-based authorization approach may not be desirable inside a client application because of the sheer amount of logic that would need to exist. To simplify the management of attribute-based authorization on the client side, each component in the application can be given a unique name that can then be linked to any number of policies. That component name can be used to determine access levels for a user. To track these access levels, the Create, Read, Update, and Delete (CRUD) paradigm can be used. Each unique component can receive a CRUD object for each user, generated when they login. This can give the application a dynamic way to authorize users.

FIG.3illustrates a system300for user access permissions, according to an example embodiment. A first process302in an application can initially define default access permissions for a component304. Then, an event306can trigger a second process308in the application to dynamically modify access permissions for some functionality of the modified component310which can, in turn, cause the user interface to display a first field312as read-only and disable a second field314. Component304can be any part of a web application architecture. The web server can respond to requests for page resources or REST APIs from clients, such as browsers and mobile apps. Some examples of web application architectures, languages, or frameworks are Java, node.js, NET, PUP, Python, and Angular.

FIG.4illustrates a system400for user access permissions, according to an example embodiment. A process402in an application, which includes communication between system A404and system B406, can define default access permissions that are dynamically altered by an event408communicated from system B406to system A404. As a result of the event408, a request from system A404to system B406can be prevented. For example, a user can attempt to go to a webpage that he/she does not have permission to access. System A404and system B406can be web browsers, clients, web application servers, applications such as single page applications, microservices, serverless architectures, user interfaces, middleware systems, databases, or other components. The event408can be a change in the user's access permissions, a scope limitation, a time duration limitation or some other condition, rule or logic. For example, a user can attempt to go to a web page that does not have an authorized route handler in the application. Web application route authorization can be done based on the client or framework being used.

Authorization Service

Authorization Service// API Responseconst routeAuth = [..{“name”: “users”,“create”: true,“read”: true,“update”: true,“delete”: true}];// Authorization Servicelet getRouteAuth = (route: string) => {// Find a matching route authorization for provided routeconst auth = routeAuth.find((obj) => {return obj.name === route; });if (auth){return auth.read;}return false;}

For example, if the route requires the user to be authenticated, the client can ask the server for the route authorizations for that user for the current time period. The server can respond with an array of objects. Each object in the array can represent a different route within the client application. The route can be identified by its name and be unique to the application. Along with the route name can be Boolean values for each CRUD permission, giving an object like the following JSON object.

{“name”: “users”,“create”: true,“read”: true,“update”: true,“delete”: true}

FIG.5illustrates a system500for user access permissions, according to an example embodiment. A process502can define default access control permissions for a system A504. System A504can make a request506to a system B508, which can send a response510that includes dynamic, granular access control permissions. System A504and system B508can be any kind of system components. For example, system A504can be a browser and system B508can be another application that provides business logic. A user can interact with an application on the browser, and then the browser can send a request to the application and receive a response from the application. CRUD can be applied to access control for a user role. A simple form can be used for inputting and updating a single user and authorization permissions might be configured for the current user as follows.

{“name”: “userForm”,“create”: false,“read”: true,“update”: true,“delete”: false}

Similarly, if a user has a restricted set of permissions for the same user form component, the user experience can be dynamically modified to reflect the access for the current user as follows. This modification to the user experience does not require additional authorization logic on the user interface application.

{“name”: “userForm”,“create”: false,“read”: true,“update”: false,“delete”: false}

FIG.6illustrates a system600for user access permissions, according to an example embodiment. A process602defines default access permissions for a user that starts a session for an application with a client component having a display604showing certain functionality. The client component604handles an event606with a process608that modifies access permissions based on the event, resulting in different functionality available on the display610. Based on the user's authorization level during a session, the client component can turn on or turn off functionality based on information provided by a server component. The client application does not need to include complicated business logic, roles, or policies, which can be handled by the server component. CRUD is much simpler to manage on the client-side and can provide the application fine-grained control over what a user is and is not allowed to do at any time. Moving the authorization to the routes and components level can allow the user interface to be as unaware as possible when it comes to authorizing a user. The user interface can use information it receives from a backend server to manage the setup of the application. For example, no business logic can be performed on the user interface related to authorization, only functional logic. For example, code can have conditions such as if this user has access to this route, then allow the user to access this route; if they do not have access, take every action to prevent the user from accessing this route, all based on information provided to the user interface when a user is authorized, and can be unique to the individual and/or their session.

The access permissions can be implemented using the “CRUD” paradigm, with a “create,” “read,” “update,” and “delete” permission for each user. Each of these permissions can be assigned a Boolean value (i.e., “true” or “false”), and the value of these permissions can determine granular file-level, object-level, and functionality-level actions which can be taken by a user at any given point in time. For example, a user having the “delete” access permission set to a value of “true” can delete any file or object to which the access permission applies. Conversely, a user having the delete access permission set to a value of “false” cannot delete any file or object to which the access permission applies. It is understood that the present disclosure is not limited to “create,” “read,” “update,” and “delete” permissions, and that additional permissions can be applied and managed in the same manner.

The access permissions can be configured to provide a granular level of control. For example, the permission can be subject to one or more limitations. The access permissions can be subject to scope limitations, temporal limitations, or a combination thereof.

For example, the access permissions can be limited to actions taken within a specific object, component, application, program, system, or project. A user responsible for interaction with a software program can be granted permission to create, read, update, and delete granular file-level, object level, and functionality-level aspects of the software program. The user's access permissions may not extend to file-level, object-level, and functionality-levels unrelated to the software program. Another user interacting with the same software program can have more limited access permissions. The latter user's access permissions can apply only to granular file-level, object-level, and functionality-levels. The latter user's access permissions also may not extend to granular file-level, object-level, and functionality-level unrelated to the software program.

As another example, the access permissions can be limited with respect to the software objects to which they apply. The foregoing embodiments described limitations placed on file related to a software program, however the present disclosure is not limited thereto. Access permissions can be limited to one or more specified files, file types, file classifications, software objects, variables, data structures, functions, state or combination thereof.

As another example, the access permissions can be temporally limited. The temporal limitation can be globally applied to the entirety of the user's permissions, such as that when the time period for access has ended the user can lose all access permissions for any purpose. Alternatively, the access permissions can be temporal with respect to the duration for a particular task, e.g., upon expiration the user can no longer perform certain actions. The task duration can be manually controlled, for example, manually started and stopped, or automatically controlled based on certain thresholds, for example, started or stopped based on a predetermined time period, specific hours within particular days, upon completion of certain tasks, or upon completion of a particular phase of a project. The control thresholds can be periodic (e.g., access permissions granted to certain users during a recurring maintenance window) or set on an as-needed basis (e.g., to allow certain users to perform a task).

An administration application can manage authorization for a user of an application. The administration application can provide access to view and modify data. This access can be based on the user's administration group membership and/or additional settings that can be determined by the application administrator role. The administration application can manage who can view or modify information in a flexible and extensible way. The administration application can provide access based on the authorized user's authorization level at a specific point in time. The administration application can leverage the CRUD pattern to determine what access is available by route, component, function, and other means. The CRUD permission can be used to set-up or modify the user experience based on the user's authorization settings at a point in time.

Traditionally, applications are developed and static roles are defined with certain privileges and access levels, etc. By combining the authorization level with CRUD, a user can be assigned an admin role, but the administration application can manipulate the way the application behaves even within the authorization role. Furthermore, the administration application can use runtime access and the ability to fine tune the rights for any user dynamically without having to create new roles, etc. For example, the administration application can grant only read permissions at a particular point in time, where otherwise the assigned role allows for create, update or delete. For example, the administration application can grant only read permissions for particular objects within the application, where otherwise the assigned role allows for create, update or delete. Some advantages of the administration application include the expansion, creation or limiting of traditional role-based access rights, without having to add new roles or updates to a front end application. This allows highly configurable permutations of roles per user and per component as the application evolves over time. The administration application can modify what a user sees in a display for an application based on a condition. For example, when a developer is using an application framework such as Angular, React or Vue, it is helpful to be able to modify displays using a condition and the CRUD pattern.

It is understood that the scope and temporal limitations are not necessarily mutually exclusive. Embodiments of the present disclosure provide that one or more scope limitations and one or more temporal limitations can be used in combination with each other or in an otherwise complementary manner.

Users can be associated into security groups for the purposes of administering access permissions. In an embodiment, all members of a security group can have the same access permissions. Newly added users can receive the same access permissions available to the group, and each security group can have one or more sub-groups that inherit the access permissions of the security group. Membership in a security group or sub-group does not preclude the application and adjustment of access permissions for an individual user, however, the alteration of a particular user's access permissions in a manner inconsistent with the security group or sub-group can result in the removal of the user from the security group or sub-group.

The access permissions can be continuously monitored and each action requested by a user can be reviewed for authorization prior to execution. For example, if at the time a user interface is presented, a user's access permissions permit the user to access a certain tool, that tool can be displayed to the user on the interface. If at a later time, the user requests that the tool perform a certain function, the user's access permissions can be verified again upon receipt of the user's request and prior to the execution of the function, to ensure the user has sufficient authorization for this action. The authorization role of the application can be checked. Other limitations passed at runtime can be checked to determine the layered rights. These runtime authorizations can be easily configured without adjusting the underlying roles.

For example, a team of users can be involved in the development of a software application. During the initial period of development when many users are writing and editing source code, all users on the team can have extensive access permissions. As development progresses and certain tasks are completed, access permissions can be removed from the users responsible for the completed tasks. In addition, as the development process requires new tasks additional users can be granted access permissions or the scope of permissions for existing users can be extended. For example, if the software application requires beta testing, users responsible for beta testing can be granted “read” permissions, or other access permissions necessary for their work without foresaid software application modifications. Once the software application is completed and deployed, access permissions for many users responsible for development can be reduced or revoked. Users responsible for supporting and maintaining the application during operation can receive the required access permissions.

As another example, established software applications can require maintenance be performed on a periodic or as-needed basis. In either case, during a maintenance break, users required to perform the maintenance can receive additional access permissions necessary to perform the maintenance work. Other users, such as end users of the application, can have access permissions restricted (e.g., to “read” only) or removed. By doing so, interference with the maintenance process can be avoided, while end users and others can be given access to more functionality than if the application were entirely unavailable.

Access permissions can also be applied in a manner to facilitate application deployment. For example, applications with multiple elements can be deployed on a rolling basis. In this case, end users can receive access permissions to particular functionalities as each becomes available, while continuing to be restricted from accessing functionalities. This approach can be applied to a “freemium” product model, where users meeting certain criteria (e.g., payment levels) receive access permissions for various functionalities with no software program modifications.

FIG.7illustrates a system700for authentication, according to an example embodiment. A client application702processes a user login by sending a message704to a server706, which sends a response708, authenticating the user.

FIG.8illustrates a system800for authentication, according to an example embodiment. A server802can provide an option804on a client application to sign in with a third party. The option804can be handled by a third party806, which communicates with the server802to authenticate the third party sign in. For example, a shopping application can allow a third party payment processing company to authenticate a purchase. For example, OpenID Connect (OIDC) may be used for authentication.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. A JWT includes three parts, a header, a payload, and a signature. For example, example code for a header

{“alg”: “HS256”,“typ”: “JWT”}Example code for a payload{“sub”: “1234567890”,“name”: “John Doe”,“email”: johndoe@email.com,“iat”: 1516239022,}and example code for a signatureHMACSHA256(header +“.” + payload, pa$sw0rd)can be formatted as [header].[payload].[signature] intoeyJhbGciOiJIUzIlN9.3ODkwliwibmFtZSI6.u6VTx2CHvo.

This payload 3ODkwJiwibmFtZSI6 can be associated with the following example code.

{“sub”: “1234567890”,“admin”: true,“name”: “John Doe”,“email”: johndoe@email.com,“iat”: 1516239022,“exp”: 1516240022,“uid”: “573hdk”,“claims”: [canEditusers,canAddProducts,canAddLocations]}{“sub”: “1234567890”,“admin”: true,“email”: johndoc@email.com,“iat”: 1516239022,“exp”: 1516240022,“uid”: “573hdk”,“roles”: [Manager,superAdmin]}

FIG.9illustrates a system900for authentication, according to an example embodiment. A mobile device902provides location information to a location server904. The location server904sends JWT to authenticate a user to a browser906. The browser906sends a request to an image microservice908and the microservice908sends JWT to authenticate the user to the mobile device902. The image microservice908can provide mobile image processing. For example, the browser906can be a payment processing application and the mobile device902can authenticate the identity of the user by scanning an optical code displayed on the browser906with a camera on the mobile device. Once the user is authenticated, certain authorization rights can be determined and/or modified.

FIG.10is an application user interface1000for a user, according to an example embodiment. Based on dynamic, granular access permissions for a particular user at a particular time, the application user interface1000can include several layout views, a header1002, a left menu1004, and a center1006. Over time and as the user interacts with the application user interface1000, access permissions can be determined and modified in a dynamic and granular way, which can change the application user interface1000. For example, the options on the left menu1004can be modified based on dynamic and granular access permissions.

FIG.11is an application user interface1100for a user, according to an example embodiment. Based on dynamic, granular access permissions for a particular user at a particular time, the application user interface1100includes an admin button1102, a users button1104, and a web address1106. ComparingFIGS.10and11illustrates how user interfaces can change for the user over time, as the user interacts with the user interface and access permissions are determined and modified. Example code associated with the admin button1102of the application user interface1100can be as follows.

<ul>...<li *ngIf=”role === ‘admin’ ∥ role === ‘auditor’ “><a routerLink=”/admin”routerLinkActive=”active”>Admin</a></li><li><a routerLink=”/products”routerLinkActive=”active”>Products</a></li>...</ul>

In another example, for the Angular framework the example code associated with the admin button1102of the application user interface1100can be as follows.

<ul>...<li *ngIf=”role === ‘admin’ ∥ role === ‘auditor’ ∥ role ===‘superAdmin’ “><a routerLink=”/admin”routerLinkActive=”active”>Admin</a></li><li><a routerLink=”/products”routerLinkActive=”active”>Products</a></li>...</ul>

CRUD can be used in code associated with the admin button1102on application user interface1100.

{CreateReadUpdateDelete}

The following example code can be associated with the users button1104on application user interface1100.

<ul>...<li><a routerLink=”/products”routerlinkActive=”active”>Products</a></li><li *ngIf=”getRouteAuth(‘users')”><a routerLink=”usersrouterLinkActive=”active”>Users</a></li>...</ul>

The following example code can be associated with the users button1104on application user interface1100.

// API ResponseConst routeAuth = [..{“name”: “users”,“create”: true,“read”: true,“update”: true,“delete”: true}];// Authorization ServiceLet getrouteAuth = (route: string) => {// Find a matching route authorization for provided routeConst auth = routeAuth.find((obj) => {return obj,.name === route;});If (auth) {return auth.read;}return false;}

Dynamic, granular control over navigation by a user can be achieved, including detecting when the user inappropriately attempts to navigate to an unauthorized web address. This is better than traditional static and global approaches that may be vulnerable to security problems with routing or navigation for an application. If the user attempts to edit the web address1106, then the following example code can be associated with checking route access permissions.

canActivate( ) : Boolean {if (!this.auth.isAuthenticated( )) {this.router.navigagte([‘login’]);return false;}return true;}// Route is the information about a specific routecanActivate(route: ActivatedRoute): Boolean {if (!this.auth.isAuthenticated( ) ∥!this.auth.getRouteAuth(route)) {this.router.navigate([‘login’]);return false;}return true;}// API ResponseConst = routeAuth = [..{“name”: “admin”,“create”: true,“read”: true,“update”: true,“delete”: true}];// Authorization ServiceLet getRouteAuth = (route: string) => {// Find a matching route authorization for provided routeconst auth = routeAuth.find((obj) => {return obj.name === route; });if (auth){return auth.read;}return false;}

FIG.12is an application user interface1200for managing users, according to an example embodiment. The application user interface1200includes an update button1202, and add user button1204and a trash button1206along with fields for entering user information.

The following example code, which is for the Angular framework, can be associated with managing users on application user interface1200.

<!--User Component --><form *ngIf=”role === ‘admin’ ∥ role === ‘user’”><div class=”form-row”><div class=”form-group col-md-6”><label for=’firstName”>First Name</label><input type=”text” id=”firstName”placeholder=”FirstName”></div><div class=”form-group col-md-6”><label for=”lastName”>Last Name</label><input type=”text” id=lastName”placeholder=”LastName”></div><div class=”form-group”><label for=”address”>Address</label><input type=”text” id=”address” placeholder=”1234 MainSt”></div><div class=”form-group”><label for=”adress2”>Address 2</label><input type=”text” id=address2Placeholder=”Apartment, studio, or floor”></div>...<button type=”submit”>Update</button></form>

The following example code can be associated with the update button1202on application user interface1200.

// User Role{“name”: “userForm”,“create”: false,“read”: true,“update”: true,“delete”: false}

The following example code can be associated with managing users on application user interface1200.

<!--User Component --><form *ngIf=”role === ‘admin’ ∥ role === ‘user’”><div class=”form-row”><div class=”form-group col-md-6”><label for=’firstName”>First Name</label><input type=”text” id=”firstName”placeholder=”First Name”[disabled]=”!auth.create ∥ !auth.update” *ngIf=”auth.read”></div><div class=”form-group col-md-6”><label for=”lastName”>Last Name</label><input type=”text” id=lastName” placeholder=”LastName”[disabled]=”!auth.create ∥ !auth.update” *ngIf=”auth.read”></div><div class=”form-group”><label for=”address”>Address</label><input type=”text” id=”address” placeholder=”1234 MainSt”[disabled]=”!auth.create ∥ !auth.update” *ngIf=”auth.read”></div><div class=”form-group”><label for=”adress2”>Address 2</label><input type=”text” id=address2Placeholder=”Apartment, studio, or floor”[disabled]=”!auth.create ∥ !auth.update” *ngIf=”auth.read”></div>...<button type=”submit”>Update</button></form>

The following example code can be associated with the add user button1204on application user interface1200.

// Admin Role{“name”: “userForm”,“create”: true,“read”: true,“update”: true,“delete”: true}

The following example code can be associated with the trash button1206on application user interface1200.

// Admin Role{“name”: “userForm”,“create”: true,“read”: true,“update”: true,“delete”: true}

The following example code can be associated with the trash button1206on application user interface1200.

// Admin Role{“name”: “userForm”,“create”: false,“read”: true,“update”: false,“delete”: false}...@Component({selector: ‘user-form’,templateUrl: ‘./user-form.component.html’})export class UserFormComponent {...getData(authorization: Object){if(authorization.read){this.http.get(‘users').subscribe(response => {// do something});}}}

The following example code can be associated with the trash button1206on application user interface1200.

// Admin Role{“name”: “userForm”,“create”: false,“read”: true,“update”: false,“delete”: false}...@Component({selector: ‘user-form’,templateUrl: ‘./user-form.component.html’})export class UserFormComponent {...getData(authorization: Object){if(authorization.update){this.http.get(‘users').subscribe(response => {// do something});}}}

The above example code illustrates how fine grained control over the individual objects of a user interface can be achieved. When access control permissions change, the following message can be displayed on application user interface1200: “We are making updates to improve your experience, some functionality temporarily disabled.”

FIG.13is a flowchart of a method1300for user access permissions, according to an example embodiment. Method1300starts at block1302. At block1304, access control permissions for users of an application are stored in a database. At block1306, a user interface is provided. At block1308, a login process is provided as part of the user interface that authenticates users. At block1310, an event is handled by dynamically modifying access to functionality in the user interface based on the event. For example, the event can be a change in the user's access permissions, a scope limitation, a time duration limitation or some other condition, rule or logic. For example, the event may be an attempt by the user to navigate to a web page that does not have an authorized route handler in the application. At block1312, it is determined whether a request from the user interface is authorized before processing the request using both the access control permissions and either a scope limitation or a temporal limitation. For example, the access permissions can be limited to actions taken within a specific object, component, application, program, system, or project. For example, the access permissions can be temporal with respect to the duration for a particular task so that upon expiration the user can no longer perform certain actions. Method1310ends at block1314. In an example embodiment, the method includes determining a default set of access control permissions for the user interface. In an example embodiment, the login process includes limiting the user interface to what is authorized by the default set of access control permissions. In an example embodiment, dynamically modifying access to functionality includes changing the access control permissions in the database. For example, when users are added or deleted from an application, the corresponding access control permissions can be changed in the database. In an example embodiment, the request from the user interface is a routing request. In an example embodiment, the application is a software development platform and the scope limitation or the temporal limitation is related to software development. In an example embodiment, the user interface includes a user management process that provides tools for adding, updating, and deleting users. In an example embodiment, the user management process changes access control permissions in the database.

FIG.14shows a block diagram of an exemplary embodiment of a system1400according to the present disclosure. For example, exemplary procedures in accordance with the present disclosure described herein can be performed by a processing arrangement and/or a computing arrangement (e.g., computer hardware arrangement)1402. Such processing/computing arrangement1402can be, for example entirely or a part of, or include, but not limited to, a computer/processor1404that can include, for example one or more microprocessors, and use instructions stored on a computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device).

As shown inFIG.14, for example a computer-accessible medium1406(e.g., as described herein above, a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc., or a collection thereof) can be provided (e.g., in communication with the processing arrangement1402). The computer-accessible medium1406can contain executable instructions1408thereon. In addition or alternatively, a storage arrangement1410can be provided separately from the computer-accessible medium1406, which can provide the instructions to the processing arrangement1402so as to configure the processing arrangement to execute certain exemplary procedures, processes, and methods, asFIG.14shows a block diagram of an exemplary embodiment of a system according to the present disclosure. For example, exemplary procedures in accordance with the present disclosure described herein can be performed by a processing arrangement and/or a computing arrangement (e.g., computer hardware arrangement)1404. Such processing/computing arrangement1404can be, for example entirely or a part of, or include, but not limited to, a computer/processor1404that can include, for example one or more microprocessors, and use instructions stored on a computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device).

As shown inFIG.14, for example a computer-accessible medium1406(e.g., as described herein above, a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc., or a collection thereof) can be provided (e.g., in communication with the processing arrangement1402). The computer-accessible medium1406can contain executable instructions1408thereon. In addition or alternatively, a storage arrangement1410can be provided separately from the computer-accessible medium1406, which can provide the instructions to the processing arrangement1402so as to configure the processing arrangement to execute certain exemplary procedures, processes, and methods, as described herein above, for example.

Further, the exemplary processing arrangement1402can be provided with or include an input/output ports1414, which can include, for example a wired network, a wireless network, the internet, an intranet, a data collection probe, a sensor, etc. As shown inFIG.14, the exemplary processing arrangement1402can be in communication with an exemplary display arrangement1412, which, according to certain exemplary embodiments of the present disclosure, can be a touch-screen configured for inputting information to the processing arrangement in addition to outputting information from the processing arrangement, for example. Further, the exemplary display arrangement1412and/or a storage arrangement1410can be used to display and/or store data in a user-accessible format and/or user-readable format described herein above, for example.

Further, the exemplary processing arrangement1402can be provided with or include an input/output ports1414, which can include, for example a wired network, a wireless network, the internet, an intranet, a data collection probe, a sensor, etc. As shown inFIG.14, the exemplary processing arrangement1402can be in communication with an exemplary display arrangement1412, which, according to certain exemplary embodiments of the present disclosure, can be a touch-screen configured for inputting information to the processing arrangement in addition to outputting information from the processing arrangement, for example. Further, the exemplary display arrangement1412and/or a storage arrangement1410can be used to display and/or store data in a user-accessible format and/or user-readable format.

As described herein, implementing and managing dynamic, granular access permissions according to embodiments of the present disclosure have a number of benefits. These include improved data security, improved privacy controls, and managed environment for application development, maintenance, and deployment.

In this description, numerous specific details have been set forth. It is to be understood, however, that implementations of the disclosed technology can be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. References to “some examples,” “other examples,” “one example,” “an example,” “various examples,” “one embodiment,” “an embodiment,” “some embodiments,” “example embodiment,” “various embodiments,” “one implementation,” “an implementation,” “example implementation,” “various implementations,” “some implementations,” etc., indicate that the implementation(s) of the disclosed technology so described can include a particular feature, structure, or characteristic, but not every implementation necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrases “in one example,” “in one embodiment,” or “in one implementation” does not necessarily refer to the same example, embodiment, or implementation, although it can.

As used herein, unless otherwise specified the use of the ordinal adjectives “first,” “second,” “third,” etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

While certain implementations of the disclosed technology have been described in connection with what is presently considered to be the most practical and various implementations, it is to be understood that the disclosed technology is not to be limited to the disclosed implementations, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

This written description uses examples to disclose certain implementations of the disclosed technology, including the best mode, and also to enable any person skilled in the art to practice certain implementations of the disclosed technology, including making and using any devices or systems and performing any incorporated methods. The patentable scope of certain implementations of the disclosed technology is defined in the claims, and can include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal language of the claims.