Intent - based Identity Access Management System and Method

Abstract

A processor; and when executed by the processor, instructions for causing the processor to receive an API token request for an authorization token and authorize an application function associated with a target API of an application; determine identity information from the API token request; retrieve attributes associated with the identity information; identify the target API and an API function profile associated with the target API for the application function; filter the attributes associated with the identity information based on the API function profile; generate the authorization token according to the filtered attributes; and send the authorization token in response to the API token request, an identity and access management system comprising a memory having the instructions.

Description

Background Art

[0001] [Cross - reference to Related Applications] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 365,374, filed on May 26, 2022, entitled "Intent - Based Identity Access Management Systems and Methods", which is hereby incorporated by reference in its entirety.

[0002] Aspects of one or more embodiments of the present disclosure relate to identity and access management systems, and more particularly, to systems and methods for dynamic authorization management.

[0003] An Identity and Access Management (IAM) system enables an organization to control user access to critical information within the organization. For example, an IAM system typically requires the integration of various separate systems to enable a single seamless login function focused on identity, authentication, and authorization, each of which may use a complex set of requirements including, for example, accurate contact data, business relationships, multi - factor authentication, least - privilege access stations, device identity, single - sign - on token management, and / or the like.

[0004] While authentication (or, put another way, determining whether a user is who they claim to be) can be fully implemented, authorization (or, put another way, defining what a user can do within a system once authenticated) can be relatively static. For example, more authorizations may be provided than are typically necessary since a lack of authorization can prevent a user's job from proceeding. Moreover, since an IAM system can focus on minimizing or reducing integration, people and processes with high authorization management loads can be required. Therefore, an organization can be forced to choose between complex authorization management that is relatively static and error-prone, or avoiding the use of least privilege access, which can increase risk to the organization.

[0005] The above information disclosed in this background section is for the purpose of enhancing understanding of the background of the present disclosure and, therefore, may include information that does not constitute prior art. SUMMARY OF THE INVENTION

[0006] One or more embodiments of the present disclosure are directed to an identity and access management system (IAM) for providing dynamic role-based access control to multiple applications.

[0007] One or more embodiments of the present disclosure are directed to a method for providing dynamic role-based access control to multiple applications.

[0008] One or more embodiments of the present disclosure are directed to an IAM system for providing dynamic intent-based access control among multiple applications.

[0009] One or more embodiments of the present disclosure are directed to a method for providing dynamic intent-based access control among multiple applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above and other aspects and features of the present disclosure will be more clearly understood from the following detailed description of exemplary and non-limiting embodiments with reference to the accompanying drawings.

[0011]

Figure 1

[0012]

Figure 2

[0013]

Figure 3

[0014]

Figure 4

[0015]

Figure 5

[0016]

Figure 6

[0017]

Figure 7

[0018]

Figure 8

[0019]

Figure 9

[0020]

Figure 10

DETAILED DESCRIPTION OF THE INVENTION

[0021] Hereinafter, embodiments will be described in more detail with reference to the accompanying drawings, in which like reference numerals refer to like elements throughout. However, the present disclosure may be embodied in various different forms and should not be construed as limited to the embodiments shown herein. Rather, these embodiments are provided by way of example so that the present disclosure will be thorough and complete, and will fully convey the aspects and features of the present disclosure to those skilled in the art. Therefore, processes, elements, and techniques that are not necessary for those skilled in the art to fully understand the aspects and features of the present disclosure may not be described. Unless otherwise noted, like reference numerals indicate like elements throughout the accompanying drawings and the described description, and thus, the redundant description may not be repeated.

[0022] Generally, authorization can pose various complexities in an IAM system because multiple applications and systems, each with its own permissions and access levels, can exist in a modern organization. Therefore, simple replication of user permissions or general grouping of user permissions has become the norm, and as a result, it can rarely be the case that the correct access rights of each user to each application are well managed. On the other hand, when providing authorization, for security purposes, the minimum amount of privilege required to perform a job may be desired, so the lack of this individual access rights management can increase the security risk to the organization. In addition, the lack of individual access rights management may not provide the flexibility desired for applications and systems to adapt to business roles at a higher granularity, resulting in localized and decentralized authorization among them and / or making it impossible to properly secure or scale authentication according to the level of access required or desired. Moreover, with the shift towards a large-scale distributed workforce and the spread of the zero-trust framework, the complexity in determining whether and to what extent authorization should be granted, such as the device used or the location of the requested access, etc., can be further added. This can exponentially increase the complexity of authorization policy management to effectively secure and manage the infrastructure.

[0023] According to one or more embodiments of the present disclosure, authorization for a user is not globally managed by an administrator (e.g., an information technology (IT) expert of an organization, etc.) using a group type authorization scheme that is mapped to local business roles individually managed by an application, but may be dynamically adjusted for each application. For example, in some embodiments, an identity and access management (IAM) system may generate an appropriate authorization token (or authorization token information) to enable a user to log in to an application with appropriate permissions and access levels. The authorization token may be dynamically generated based on various user attributes that may be centrally managed by the IAM system, access boundaries of various application functions, and / or the like.

[0024] In some embodiments, the access boundaries of various application functions may be defined by the application based on business roles, business goals, business policies, and / or other rules and requirements provided by the application to enable various application functions when certain user attributes are present. Thus, the IAM system may provide an appropriate interface (e.g., an application programming interface (API)) to define the inputs expected in the authorization token for the application to enable a particular application function, which may be associated with various user attributes and contact information so that the authorization token can be properly formatted for the application to understand and enable appropriate permissions and access levels for the user. Therefore, in some embodiments, the resulting authorization token may have a relatively small payload by reducing the amount of unnecessary information that the application has to process.

[0025] In some embodiments, the user attributes and various other contact information used to generate authorization tokens may be stored in a centralized data store (e.g., a contact master data management (MDM) service) managed by an IAM system that is accessible by applications upon request. Thus, rather than each application managing its own user attributes and contact information that may not be shared with other applications, the centralized data store can be the source of ground truth for all user attributes and contact information used by each of the applications that have subscribed to the centralized data store to drive authorization for the applications. By using the centralized data store as the source of ground truth for holistic user data (e.g., user attributes and contact information), the operational reliability of the up-to-date data environment can be leveraged while flexibility in the source of truth for user data is created.

[0026] In some embodiments, rather than being locked to a specific set of fields or attributes, user attributes and contact information may be stored in a common data format for use by multiple different applications, whereby it can be replaced over time without changing the front-end components of the authentication and authorization services. For example, in some embodiments, a specific data structure need not be defined, which may enable complex relationships, optionally used to make downstream authentication and authorization decisions, to be mapped in a centralized data store. Therefore, instead of a single level hierarchy of user data (e.g., user attributes and contact information), complex parent / child relationships, groupings, and / or references to extensible subgroups may be implemented to improve or maximize flexibility. Moreover, in some embodiments, the centralization of user data may enable seamless integration into future systems using lightweight code for standard software data mechanisms, such as JSON over a pub / sub bus, JSON returned from a REST API, SQL, and / or the like.

[0027] In some embodiments, authentication can be scaled as needed or desired to dynamically provide appropriate authorization to a user. For example, in some embodiments, an IAM system may combine a username / password authentication mechanism with a more complex multi-factor authentication (MFA) mechanism, such as a client-based push notification, a hard or soft token time-based one time password (TOTP), a smart card, biometrics, or any other suitable authentication mechanism. Authentication may then be used downstream to set authorization policies and access levels based on the authentication mechanism used, and redundancy may be created to add flexibility. For example, if a user is authenticated without using an appropriate authentication mechanism for a particular application or to enable a particular application feature within an application, the IAM system may require the user to provide an appropriate authentication mechanism before being authorized at a permission or access level suitable for using the particular application.

[0028] In some embodiments, a user's permission or access level for a particular application may be dynamically changed by an IAM system as needed or desired (e.g., for each access request, when an event occurs, and / or the like). For example, in some embodiments, the permission or access level granted to a user for a particular application may be time-limited according to one or more of user attributes and / or the occurrence of an event. As a non-limiting example, a user may be tagged with an attribute (e.g., a role attribute) indicating that the user is a product deployment engineer, and thus may require superuser permission for a particular application during a production deployment event, but may not require as much permission at other times. In this example, the IAM system may be communicatively connected to a global change request system to identify a change request corresponding to the production deployment time that may affect a particular application, and may change the user's access level for the particular application over a suitable duration at the production deployment time. As another example, the access level granted to a user for a particular application may be dynamically changed based on a security event, such as when the organization is currently under threat or attack. In this case, the IAM system may restrict access rights to applications and systems for all or some of the users to reduce the risk to the organization until the threat or attack subsides.

[0029] In some embodiments, the IAM system may include an artificial intelligence (AI) policy engine that uses a supervised machine learning model to determine and, as appropriate, dynamically adjust a user's permissions and access levels. For example, the number of attributes that define a user, the applications accessed by the user, the device the user is using, and the location where the user is located may be some of the factors used to train a model that determines whether authorization is permitted. The recommendations and actions provided by the AI policy engine may then be verified by a human policy engine (e.g., a human verification policy engine) to ensure that such recommendations and actions are appropriate and correct, while at the same time enabling the AI policy engine to continuously strengthen and train itself based on a training set that is continuously verified.

[0030] Through this combination of rapid AI decision-making and human oversight, the authentication mechanisms used, and the ground truth sources for user attributes and contact information, the overall complexity of rich security privileges can be facilitated for an application without a large overhead for pre-authorization for access. Thus, in some embodiments, access to an application can be permitted more quickly while using human insight at defined intervals with fewer interruptions.

[0031] According to one or more embodiments of the present disclosure, authorization for a user may be dynamically adjusted based on the user's intent with respect to a particular application function. For example, in some embodiments, an IAM system logs in to a first application (e.g., a calling application) and uses it to generate an authorization token (or authorization token information) suitable for enabling a user using the first application to access an application function of a second application (e.g., a target application). In this case, the user has logged in to the first application with appropriate permissions and access levels for the first application, but in order to access the application function of the second application from the first application, the second application may request an authorization token suitable for enabling the application function for the user. However, rather than providing all of the user's authorization and access levels to the second application based on all of the user's user attributes, the authorization token may be dynamically adjusted based only on the user attributes required to enable the application function in the second application, whereby the payload of the authorization token is reduced, and at the same time, an appropriate amount of authorization required by the second application to enable the corresponding application function for the user can be enabled.

[0032] Here, the above and other aspects and features of the present disclosure will be described in more detail with reference to the figures.

[0033] FIG. 1 shows an environment of an identity and access management system according to one or more embodiments of the present disclosure.

[0034] Referring to FIG. 1, in some embodiments, the environment 100 may include a corporate environment 100 of an organization (e.g., a business). The corporate environment 100 may include an identity and access management (IAM) system 102 to provide dynamic role-based access control (dynamic RBAC) to one or more applications App 1 to App N (where N is a natural number) for a plurality of users of user devices 104a and 104b (hereinafter collectively referred to as the plurality of users 104 or the plurality of user devices 104, or individually referred to as the user 104 or the user device 104). For example, the IAM system 102 may identify, authenticate, and authorize each of the users 104 via the network 106 to log in to one or more applications App 1 to App N at appropriate permissions and access levels based on various user attributes and contact information of the users, the roles of the users within the organization, the access boundaries of various application functions, event information from other corporate systems and subsystems, and the like. Thus, each of the users 104 may be granted access to different ones of the applications App 1 to App N, or may be granted different access or permission levels to the applications App 1 to App N. For example, a user may be granted read and modify permissions to a particular file based on his or her specific role and attributes, while another user may not be granted access permissions to those same files or may be granted only read permissions based on his or her specific role and attributes.

[0035] In summary, when user 104 logs in to a specific application (e.g., App 1) managed by application provider 122 via user interface UI or user experience UX using a suitable authentication mechanism (e.g., username and password, multi-factor authentication mechanism, hard or soft token time-based one-time password (TOTP), smart card, biometrics, and / or the like), application provider 122 may communicate with one or more identity providers 124 to authenticate user 104. Identity provider 124 may generate a suitable identity token based on the authentication mechanism used and provide the identity token to IAM system 102. IAM system 102 may use the identity token to identify the application-specific user attributes of the user expected by a specific application in order to provide suitable permissions and access levels for the user. IAM system 102 may generate and provide an authorization token (or authorization token information) to identity provider 124 according to the application-specific user attributes, and identity provider 124 may generate and provide a login token to complete the user's login. The login token may include at least the authorization token (or authorization token information) to enable the application to provide suitable permissions and access levels to the user. In some embodiments, the login token may include information combined from the identity token and the authorization token.

[0036] Network 106 may be structured to enable the exchange of data, values, instructions, messages, and / or the like between the IAM system 102 and the user device 104. In various embodiments, network 106 may include any suitable wired or wireless network (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), a cellular communication network, and / or the like).For example, network 106 may include Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA) (e.g., Evolution-Data Optimized (EVDO)), Universal Mobile Telecommunications Systems (UMTS) (e.g., Time Division Synchronous CDMA (TD-SCDMA or TDS)), Wideband Code Division Multiple Access (WCDMA (registered trademark)), Long Term Evolution (LTE), evolved Multimedia Broadcast Multicast Services (eMBMS), High-Speed Downlink Packet Access (HSDPA), Universal Terrestrial Radio Access (UTRA), Global System for Mobile Communications (GSM (registered trademark)), Code Division Multiple Access 1x radio transmission technology (1x), General Packet Radio Service (GPRS), Personal Communications Service (PCS), 802.11X, Bluetooth (registered trademark), Wi-Fi (registered trademark), any suitable wired network, combinations thereof, and / or the like.

[0037] FIG. 1 shows only a portion of enterprise environment 100 that includes IAM system 102, identity provider 124, and application provider 122, but the present disclosure is not limited thereto. For example, as will be understood by those skilled in the art, enterprise environment 100 may include a variety of other enterprise systems and subsystems, such as a human resource (HR) management system, a global change request management system, an enterprise resource planning (ERP) system, various security systems, and / or the like. These systems and subsystems may be connected directly to IAM system 102 (e.g., via local wired or wireless communication) or via network 106 (e.g., a WAN, the Internet, a cellular network, and / or the like). Thus, in some embodiments, IAM system 102 may receive and analyze various information (e.g., event information) from these enterprise systems and subsystems to determine whether authorization can be granted at any given point in time and to what extent.

[0038] FIG. 2 shows an identity and access management system according to one or more embodiments of the present disclosure.

[0039] Referring to FIG. 2, IAM system 102 may be communicatively coupled to application provider 122 and identity provider 124. For example, in some embodiments, IAM system 102 may include an application interface (e.g., an API) 212 for communicating with application provider 122 and a secured interface 214 for communicating with identity provider 124. FIG. 2 shows each of application interface 212 and secured interface 214 as separate interfaces, but the present disclosure is not limited thereto, and in other embodiments, application interface 212 and secured interface 214 may be part of the same interface.

[0040] Interfaces 212 and 214 may be or include a wired or wireless communication interface (e.g., a jack, an antenna, a transmitter, a receiver, a transceiver, a wire terminal, and / or the like) for data communication with the IAM system 102. In various embodiments, communication via interfaces 212 and 214 can be direct (e.g., local wired or wireless communication) or via network 106 (e.g., a WAN, the Internet, a cellular network, and / or the like). For example, interfaces 212 and 214 may include a Wi-Fi® transceiver for communicating via a wireless communication network. In another example, interfaces 212 and 214 may include an Ethernet® card and port for transmitting and receiving data via an Ethernet®-based communication link or network. In another example, one or more of interfaces 212 and 214 may include a cellular or mobile phone transceiver. In various embodiments, interfaces 212 and 214 may support various protocols (e.g., TCP / IP, User Datagram Protocol UDP, Hypertext Transfer Protocol HTTP, Internet Message Access Protocol IMAP, Simple Mail Transfer Protocol SMTP, and / or the like) and / or data communication interfaces (e.g., an API, a web service, and / or the like) for facilitating data communication with application provider 122 and identity provider 124.

[0041] The application provider 122 may manage applications App 1 to App N and define various application functions and their access boundaries for each of the applications App 1 to App N. For example, the application provider 122 may communicate with the IAM system 102 to define application functions and their access boundaries based on, for example, business roles, business policies, mappings, functions, and / or the like. The application provider 122 may provide application requirements (e.g., formatting and input requirements) to the IAM system 102 to generate appropriate authorization tokens (or authorization token information) that can be understood by the application to provide the appropriate level of access to the user. The application requirements may correspond to user attributes and formatting requirements expected by the application to enable certain ones of the application functions. For example, in some embodiments, the IAM system 102 may expose various APIs (e.g., via the application interface 212) to the application provider 122 to enable the application provider 122 to define application functions and application requirements (e.g., formatting and expected input requirements) for which authorization tokens can be used by the application to determine the user's permissions and access levels.

[0042] Identity provider 124 may provide identity and / or authentication services for applications App 1 to App N to authenticate users. For example, when a user logs in to an application using user device 104 (e.g., via the application's UI or UX), the user may provide login information (e.g., authentication mechanisms such as username and password, multi-factor authentication mechanism, hard or soft TOTP, smart card, biometrics, and / or the like) in the UI or UX (e.g., login page, access device, and / or the like). The login information may be provided to identity provider 124 to identify and authenticate the user. For example, in response to the login information, identity provider 124 may generate an identity token suitable according to the authentication mechanism provided by the user to identify and authenticate the user, and provide the identity token to IAM system 102 to determine user authorization within the application. For example, the identity token may include identity information (e.g., username or other authentication mechanism used to authenticate the user) and group information associated with the user (e.g., active directory (AD) group information). In some embodiments, the identity token may also identify the application for which the user is requesting a login. Some non-limiting examples of identity provider 124 may include, for example, Azure (e.g., Azure B2C, Azure AD, and / or the like), Okta, Google, Facebook (registered trademark), and / or the like.

[0043] The IAM system 102 may generate an appropriate authorization token (or authorization token information) for a user to log in to and access an application based on the app functions and app requirements defined for the application by the corresponding application provider 122, the various user attributes that are specific to the user and used by the application to determine the user's permissions and access levels, and the authentication mechanisms used to authenticate the user. For example, in some embodiments, the IAM system 102 may generate a corresponding authorization policy in accordance with the app functions and app requirements defined by the application provider 122. When a user logs in to a particular application, the corresponding authorization policy for the particular application may be driven by the user attributes of the user identified using the identity token. Thereby, if certain user attributes exist, the corresponding authorization policy may be executed to generate an appropriate authorization token (or authorization token information) for the particular application to provide the level of access to the particular user according to the information stored in the authorization token.

[0044] In some embodiments, the identity token may be used to identify whether the authentication mechanism used to authenticate the user is sufficient to grant authorization for a particular authorization policy. For example, when a user is switching through an application using SSO, subsequent applications may have different authentication requirements than the previous application, such that the IAM system 102 may require the user to authenticate again using a different authentication mechanism (e.g., a multi-factor authentication mechanism) before being granted the appropriate permissions and access levels for using the subsequent application. Thus, if certain attributes are present and the authentication mechanism used to authenticate the user is appropriate, the corresponding authorization policy may be executed to generate an authorization token (or authorization token information), which may then be used by the identity provider 124 to generate a login token to complete the user's login to the corresponding application. The corresponding application may process the login token to provide the user with the appropriate permissions or access levels based on the information stored in the authorization token (or authorization token information) within the login token.

[0045] More specifically, the IAM system 102 may include a processing circuit 216 having one or more processors 218 and a memory (e.g., one or more memories or other storage devices) 220. Although shown as a single processing circuit 216 in FIG. 2, the processing circuit may be distributed and implemented across multiple computing devices and storage devices. The processing circuit 216 may be communicatively coupled to an application interface 212 and a securitization interface 214, whereby the processing circuit 216 and its various components can transmit and receive data via interfaces 212 and 214. The processor 218 may be implemented using one or more general-purpose processors, ASICs, one or more FPGAs, DSPs, a group of processing components distributed across various geographical locations or housed in a single location or device, or other suitable electronic processing components.

[0046] Memory (e.g., a memory device, memory unit, one or more memory devices, storage device, or the like) 220 may be implemented using RAM, NVRAM, ROM, flash memory, hard disk storage, cloud storage, and / or other suitable electronic storage devices. Memory 220 stores data and / or computer code for facilitating at least a portion of the various processes described herein. Memory 220 includes tangible non-transitory volatile or non-volatile memory. Memory 220 may include a database component, object code component, script component, and / or any other type of information structure for supporting the various activities and information structures described in the present application. According to one embodiment, memory 220 is communicatively coupled to processor 218 via processing circuitry 216 and includes computer code for performing one or more processes described herein (e.g., by processing circuitry 216 and / or processor 218). For example, memory 220 stores instructions or programming logic that, when executed by processor 218, controls the operation of IAM system 102. In some embodiments, processor 218 and memory 220 may form or be part of various processing circuits in IAM system 102.

[0047] In some embodiments, memory 220 includes a contact master data management (MDM) service 222, an authentication service 224, and an authorization service 226. Services 222-226 receive inputs from application provider 122, identity provider 124, and other data sources (e.g., other enterprise systems and subsystems), determine actions for IAM system 102 based on the inputs, generate control signals based on the actions, and are each configured to provide the generated control signals to interfaces 212 and 214 for communicating with application provider 122 and identity provider 124, respectively. FIG. 2 shows that each of contact MDM service 222, authentication service 224, and authorization service 226 is part of the same processing circuit 216, but the present disclosure is not limited thereto. For example, each of services 222-226 may be implemented on one or more internal processing circuits with respect to IAM system 102, or may be implemented on one or more external processing circuits as part of a cloud-based computing system.

[0048] In some embodiments, the contact MDM service 222 may include a centralized data store for storing each user attribute of user 104 and other contact information used to generate authorization tokens for accessing each of applications App 1 to App N (e.g., see FIG. 1). For example, user attributes may include core attributes (e.g., name (e.g., first name, middle name, and last name), date of birth (DOB), address, email, and / or the like), role attributes (e.g., department, position, and / or the like), scope attributes (e.g., function, role, and / or the like), group attributes (government, private, and / or the like), hierarchy attributes (e.g., organizational hierarchy, supervisor, and / or the like), and / or other attributes and tags defining various attributes of the user and other contact information used by various different applications App 1 to App N, whereby the contact MDM service 222 stores all of the user attributes and contact information required by applications App 1 to App N to provide appropriate permissions and access levels to the user. These attributes may be distinct or may partially overlap with each other depending on the attribute types used by different applications App 1 to App N, and different applications App 1 to App N may use different types and / or combinations of attribute types. For example, one application may require specific role and group attributes in the authorization token, while another application may require specific scope and hierarchy attributes in the authorization token, and there may be some overlap between them depending on the types of attributes used by various applications to provide appropriate authorization. Thus, the contact MDM service 222 functions as a centralized data store for all of the user attributes and contact information used by various different applications App 1 to App N to provide appropriate permissions and access levels to various different users 104 based on those specific attributes stored in the contact MDM service 222.

[0049] The contact MDM service 222 may communicate and / or synchronize user attributes and other contact information stored by the identity provider 124 and other enterprise systems or subsystems (e.g., HR management system), such that all of the user attributes and other contact information used by each of the applications App 1 to App N may be stored internally. In some embodiments, the authentication service 224 and / or authorization service 226 may query the contact MDM service 222 for user attributes and contact information as necessary or desired to authenticate and / or authorize the user to log in to the applications App 1 to App N at appropriate permissions and access levels. For example, the authentication service 224 may query the contact MDM service 222 using the information stored in the identity token provided by the identity provider 124 to generate an application-specific user profile. The application-specific user profile may be specific to the particular application for which the user is requesting to log in, such that it stores only the user's user attributes from among all of the user attributes stored by the contact MDM service 222 that are used by the particular application to grant the user appropriate permissions and access levels.

[0050] In some embodiments, the contact MDM service 222 may be accessible by applications App 1 to App N to provide desired contact information to the applications App 1 to App N in response to requests. For example, in some embodiments, the contact MDM service 222 may be implemented based on a public and subscription model, whereby applications subscribed thereto may request user attributes and contact information about user 104, and the contact MDM service 222 may disclose responses to subscribed applications. Thus, instead of each of the applications App 1 to App N managing its own contact information that may not be shared, the contact MDM service 222 may be the source of ground truth for all user attributes and other contact information used to drive authorization for each of the various applications App 1 to App N.

[0051] The authentication service 224 may communicate with the identity provider 124 to identify and authenticate the login information of user 104. For example, the authentication service 224 may communicate with the identity provider 124 to provide a single sign-on (SSO) service 232, a multi-factor authentication service 234, and / or the like. The identity provider 124 may identify and authenticate the user according to the authentication mechanism used, generate an identity token, and provide it to the authentication service 224. The identity token may include, for example, the user's identity information, the user's Active Directory (AD) group information, and / or the like.

[0052] In some embodiments, the authentication service 224 may parse identity information about the user from the identity token and may query the contact MDM service 222 based on the identity information to retrieve the user attributes of the user. In some embodiments, the authentication service 224 may identify the application corresponding to the user login and may filter the user attributes according to the application profile for the application. For example, as discussed in more detail below, in some embodiments, when the authorization service 226 generates an authorization policy for the application based on the app functions 244 and app requirements 245 of the application, the authorization service 226 may generate an application profile for the application corresponding to all of the various sets and combinations of user attribute types used to enable the various application functions of the application. Therefore, when the user logs in to the application, the authentication service 224 uses the application profile for the application to filter the user attributes of the user stored in the contact MDM service 222 according to the user attribute types used by the application, thereby generating an application-specific user profile (e.g., an app user profile) that includes only the user attributes (e.g., user attribute sets) of the user relevant to the application when determining the permissions or access levels to be granted to the user. The authentication service 224 may provide the app user profile to the authorization service 226 to select and enforce one or more corresponding authorization policies to generate an appropriate authorization token according to the user attribute set in the app user profile.

[0053] In some embodiments, the authentication service 224 may provide a federation service 236 to the identity provider 124, for example when supporting SSO and the like. In some embodiments, the authentication service 224 may determine the authentication mechanism used to authenticate the user from the identity token.

[0054] In some embodiments, the authentication service 224 may communicate with the authorization service 226 to determine whether the authentication mechanism used is appropriate for the level of access that can be granted to the user by the authorization service 226. For example, if the authorization policy used to generate the authorization token indicates that different authentication mechanisms are required to grant the corresponding permissions and access levels, the authorization service 226 may communicate with the authentication service 224 to request that the user be re-authenticated using the different authentication mechanism before granting authorization (e.g., before generating or providing the authorization token). In this example, the authentication service 224 may communicate with the identity provider 124 to request that the user provide a different authentication mechanism to generate and provide a new identity token according to the different authentication mechanism that is appropriate for the authorization granted by the authorization service 226, and the new identity token may be used to generate an authorization token for authorizing the user.

[0055] As a non-limiting example, in the case of SSO, when switching from a public application where the user receives an SSO identity token to another application that requests a multi-factor authentication identity token, the authorization service 226 may communicate with the authentication service 224 to request a multi-factor authentication identity token to generate an authorization token when enforcing the authorization policy. The authentication service 224 may communicate with the identity provider 124 to authenticate the user based on the multi-factor authentication mechanism, and the identity provider 124 may generate and provide a new identity token corresponding to the multi-factor authentication mechanism used to authenticate the user.

[0056] The authorization service 226 may generate an authorization policy according to the app functions 244 and app requirements 245 provided by the application provider 122, and execute an appropriate one of the authorization policies to generate an authorization token according to the set of user attributes of the user in the app user profile. For example, in some embodiments, the authorization service 226 may include a plurality of policy engines 242 that may define the authorization policies for each of the applications App 1 to App N to generate an appropriate authorization token for the user to access a specific application at an appropriate permission and access level. The authorization policy may be generated based on the app functions 244 and app requirements 245 defined by the application provider 122, and the authorization policy may be executed to generate an authorization token based on the specific user attributes and contact information (e.g., set of user attributes) of the user stored in the app user profile for the user and the authentication mechanism used to authenticate the user.

[0057] For example, in some embodiments, the app functions 244 may correspond to different functions of the application that may be provided based on the user's permissions and access levels, and the app requirements 245 may define the expected inputs (e.g., user attributes) and formatting requirements of the authorization token to enable the app functions 244. Therefore, the app functions 244 may define the access boundaries of the application, and the app requirements 245 may define the specific business roles, business goals, business policies, mappings, and / or the like used by the application to provide the permissions and access levels required to access a specific app function 244 of the application.

[0058] The policy engine 242 may generate various authorization policies according to the application functions 244 and application requirements 245 defined by the application provider 122, and for each of the authorization policies, when present, associate (e.g., link or map) it with various expected user attributes that trigger the execution of the authorization policy to generate an authorization token. Thus, corresponding application profiles for each of the applications App 1 to App N may be generated. Therefore, when a user requests to log in to a specific application, the authentication service 224 may use the application profile of the specific application to filter the user attributes retrieved from the contact MDM service 222, thereby generating an application user profile for the user, and the authorization service 226 may use the application user profile to determine which of the authorization policies should be executed to generate an appropriate authorization token for the specific application.

[0059] As a non-limiting example, the app function 244 may provide that "people enrolled in the accounting department should be able to read and modify account information to adjust resources." In this example, the corresponding app requirement 245 may define the user attributes required by the application to determine that the user is enrolled in the accounting department in order to enable the app function 244 to read and modify the user's account information. The policy engine 242 may generate an authorization policy that, when executed in accordance with the app function 244 and the corresponding app requirement 245, generates an authorization token to enable such an app function 244. The policy engine 242 may associate (e.g., link or map) the authorization policy with specific user attributes (e.g., job title, department, and / or the like) in the corresponding application profile, and the corresponding application profile may be used by the authentication service 224 to retrieve specific user attributes from the contact MDM 22 that identifies whether the user is enrolled in the accounting department (e.g., functional role) so as to be mapped to the application role (e.g., business role) defined by the app function 244. Thereby, when the user logged into the application has the correct user attributes, the authorization policy may be executed to generate an authorization token indicating that the user is enrolled in the accounting department and is therefore authorized to read and modify account information to adjust resources.

[0060] In some embodiments, to support legacy systems that use a general grouping of user permissions to provide access, the policy engine 242 may generate authorization tokens based on groupings in an Activity Directory (AD) group 246 that are mapped to local business roles that are individually managed by an application. For example, since some of applications App 1 to App N may already be configured to provide access based on local mappings of business roles to various groups in the AD group 246, the policy engine 242 may generate an authorization policy that utilizes the groups in the AD group 246 to generate authorization tokens. The groups in the AD group 246 may be distinguishable from the user attributes and contact information in the contact MDM 222 in that they may refer to groups of people (e.g., the management department) rather than individual attributes of a user (e.g., the management coordinator). In this case, there may be a transitional period during which the operations team may evaluate the AD groups and convert the AD groups into a suitable set of user attributes that are used by the application to determine user authorization. If there are conflicts (e.g., overlapping user attribute sets and AD groups), the application provider 122 may define how the IAM system 102 should handle the conflicts. However, the present disclosure is not limited thereto, and in other embodiments, the AD group 246 may be omitted.

[0061] Accordingly, in various embodiments, the policy engine 242 may generate authorization policies based on the app functionality 244 and / or the AD group 246, which may be selectively executed according to the specific user attributes of the user and the authentication mechanism used to authenticate the user to generate suitable authorization tokens that can be used by the application to provide appropriate permissions and access levels to the user. The policy engine 242 will be described in more detail hereinafter with reference to FIG. 3.

[0062] Figure 3 shows a policy engine of an authorization service such as authorization service 226 according to one or more embodiments of the present disclosure.

[0063] Referring to FIG. 3, the policy engine 242 may include a logic policy engine 302, a human policy engine (e.g., human verification policy engine) 304, and an AI policy engine 306 to determine permissions and access levels that may be granted to a user based on the user's specific user attributes. The logic policy engine 302 may generate an authorization policy in accordance with the application functions 244 and application requirements 245 defined by the application provider 122. The human policy engine 304 may define the AD group 246 (e.g., via the system administrator 310) such that the authorization policy can be generated in accordance with the AD group 246. The human policy engine 304 may ignore the authorization granted to the user (e.g., by the logic policy engine 302) and may adjust the user's permissions and access levels as appropriate. The AI policy engine 306 may be trained over time to appropriately select and / or adjust the authorization policy using a supervised machine learning model that can be verified and enhanced by the human policy engine 304.

[0064] In some embodiments, the authorization policy may be stratified into various suitable authorization hierarchies 308 (e.g., Tier 1 to Tier M) according to the level of access that may be granted to the user, such that the lower the tier, the more authorization rights are granted to the user. For example, the top tier Tier 1 may include a minimum constraint authorization policy to generate an authorization token that provides the user with natural rights (e.g., minimum authorization rights or global authorization rights) across various applications, and the bottom tier Tier M (where M is a natural number) may include a maximum constraint authorization policy to generate an application-specific authorization token that provides the maximum authorization rights for the user in terms of an application unit or a service unit.

[0065] In some embodiments, each of the tiers (e.g., Tier 1 through Tier M) may be associated (e.g., linked) with one or more user attributes, such that when a user has a particular user attribute, the appropriate tier may be selected so that its authorization policy can be executed to generate an authorization token. For example, the Logic Policy Engine 302 may generate a corresponding application profile for each of the tiers that defines the user attributes required to execute the authorization policy of the tier, and the application profile may be used by the Authentication Service 224 to filter user attributes from the Contact MDM 222 in response to a user login request as discussed above. The user attributes associated with each of the tiers may depend on the app function 244 or AD group 246 used to generate the authorization policy for the corresponding tier. For example, in some embodiments, the Logic Policy Engine 302 may analyze the app function 244 and app requirements 245 to determine the user attributes required to associate (e.g., link) the user with an application role (e.g., business role) defined by the corresponding app function 244. As another example, in some embodiments, the Human Policy Engine 304 may (e.g., via the System Administrator 310) define groups in the AD group 246, such that the Human Policy Engine 304 may convert the groups in the AD group into various user attribute sets during a transition period in which the application can be associated with the corresponding app function 244. In some embodiments, the AI Policy Engine 306 may assist in migrating the groups in the AD group to various user attribute sets, which may be verified by the Human Policy Engine 304.

[0066] In some embodiments, the authorization policy in authorization layer 308 may define the authentication requirements needed to authorize a user. For example, while executing a particular layer's authorization policy based on a set of user attributes of an app user profile, the authorization policy may indicate that different authentication mechanisms are needed to properly authenticate the user for the corresponding application function. In this case, logic policy engine 302 may request different authentication mechanisms for the user from authentication service 224 to authorize the user for the corresponding application. In some embodiments, if a user cannot be authenticated via different authentication mechanisms, authorization may be denied, or an authorization policy of a different, less restrictive authorization layer may be selected and executed based on the previously provided authentication mechanism.

[0067] Thus, in some embodiments, when user 104 logs into the application via the app UI / UX, identity provider 124 may generate an appropriate identity token according to the authentication mechanism used, and provide the identity token to authentication service 224. The identity token may include identity information corresponding to the authentication mechanism used, AD group information associated with the user, and / or the like. Authentication service 224 may retrieve user attributes from contact MDM 222 using the identity information, filter the user attributes according to the corresponding application profile of the application to form a set of user attributes, and generate an app user profile. Authorization service 242 (e.g., logic policy engine 302) may use the set of user attributes in the app user profile to identify one or more authorization levels 308 associated with one or more of the user attributes in the set of user attributes, and execute the authorization policies of the one or more authorization levels 308. Logic policy engine 302 may determine whether the authentication mechanism used to authenticate the user is appropriate for the authorization policy from the authorization policies of the one or more authorization levels 308. If the authentication mechanism is appropriate, logic policy engine 302 may generate an authorization token according to the authorization policy, and the authorization token may be provided to identity provider 124 to complete user 104's login to the application with the appropriate permissions and access levels defined by the authorization token. For example, identity provider 124 may generate a login token including at least the authorization token (or authorization token information) to complete the user's login. In some embodiments, the login token may include information combined from the identity token and the authorization token. The permissions and access levels provided by logic policy engine 302 may then be adjusted and / or ignored by human policy engine 304 as necessary or desired.

[0068] The actions of the Logic Policy Engine 302 and the Human Policy Engine 304, and the interactions between them, may be observed by the AI Policy Engine 306 to learn how to grant appropriate permissions and access levels over time. For example, the permissions and access levels granted by the Logic Policy Engine 302 and any adjustments to them by the Human Policy Engine 304 may be used as a labeled dataset to train the AI Policy Engine 306 to make authorization recommendations in a training mode. In some embodiments, the AI Policy Engine 306 monitors other enterprise subsystems 212, user activity, the type of user device being used, the location of the requested access, the user attributes used to select an authorization hierarchy, and / or the like, in order to make recommendations to change the authorization threshold level and / or to recommend changes to the permissions and access levels granted to the user as needed or desired. The recommendations of the AI Policy Engine 306 may then be verified by the Human Policy Engine 304 as part of a cross-validation process, and if the recommendations are appropriate and accurate enough, the AI Policy Engine 306 may dynamically change the authorizations granted to the user as needed or desired in an assist mode.

[0069] For example, in some embodiments, the AI policy engine 306 may monitor events occurring in the enterprise environment 100 and modify the permissions provided to the user 104 as needed or desired. For example, in some embodiments, the AI policy engine 306 may communicate with the security system of the enterprise subsystem 312 to change the authorization threshold level depending on the threat level. In this case, the authorization threshold level may be changed, for example, by restricting the execution of the authorization policies of some levels of the lower authorization hierarchy 308 or by increasing the authentication requirements for at least some of the authorization hierarchies 308. For example, the app function 244, the authorization policies generated by the logic policy engine 302, the user attributes associated therewith, the level of authentication required by the authorization policies, and / or the like may be classified by the AI policy engine 306 into various privileges, and those classified as higher privileges may be prevented from being used until normal operation resumes.

[0070] As another example, the AI policy engine 306 may communicate with the global change request system of the enterprise subsystem 312 to identify production deployment events that can be granted to some users having user attributes for which time-limited authorization is appropriate during that time. For example, in response to a production deployment event, the AI policy engine 306 may identify users having production deployment tag attributes to grant higher permissions or access levels to the identified users for the affected applications during the duration of the production deployment event.

[0071] In some embodiments, the AI policy engine 306 may observe user actions to determine whether the user's permissions and access levels may be changed. For example, the AI policy engine 306 may identify the applications accessed by the user, the devices used, the location and / or network of the requested access, and / or the like, in order to determine a discrepancy to appropriately adjust the user's authorization threshold. For example, if the requested access is from a trusted location, the AI policy engine 306 may lower the authorization threshold for the user. On the other hand, if the user requests access to a rarely used application from an unknown device, an untrusted location, and / or the like, the AI policy engine 306 may raise the authorization threshold for the user.

[0072] As a non-limiting example, the AI policy engine 306 may determine that a user who always logs in at a similar time, has the same manager, has a predecessor in the same role of the user with the same access, and / or the like, and has similar privileges to other users, may be permitted access to the application. In addition, if the device is running the same software version, no security incidents have occurred from the same city, the same broadband network, and soft time-based TOTP is used for authentication, the AI policy engine 306 may grant the user a higher permission or access level even though the user is not connected to their normal network.

[0073] The Human Policy Engine 304 may be used to verify the recommendations and actions of the AI Policy Engine 306. For example, in some embodiments, the grouping of similar attributes for granting authorization may be combined with alerts and logging when a user is identified as having a higher risk. System administrators, user managers, other users, the users themselves, application owners, and / or the like may all be identified to provide safeguards against abuse. Additionally, these same users may be used as a verification system for other users who do not have authorization. For example, a user may be prompted on a screen stating that they have been denied, but since the AI Policy Engine 306 may be unsure of its output, quick buttons may be presented to a plurality of other users to ask whether they can authorize the access that these users have attempted. The Human Policy Engine 304 may allow the AI Policy Engine 306 to continuously enhance and train itself based on a training set that is continuously verified. The AI Policy Engine 306 may be further trained through periodic audits of users that it has determined it may have access to, ensuring both that these users should still be permitted and that the original determination was actually correct. Thus, in some embodiments, access to an application may be permitted more quickly while using human insight at defined intervals with fewer interruptions.

[0074] FIG. 4 is a flowchart of a method for generating an authorization policy according to one or more embodiments of the present disclosure. For example, method 400 may be performed by authorization service 226 (e.g., policy engine 242) shown in FIGS. 2 and 3. However, the present disclosure is not limited thereto, and the operations shown in method 400 may be performed by any suitable one or combination of components and elements of the one or more exemplary embodiments described above. Further, the present disclosure is not limited to the sequence or number of operations of method 400 shown in FIG. 4, and may be changed to any desired sequence or number of operations as recognized by those skilled in the art. For example, in some embodiments, the order may vary, or method 400 may include fewer or additional operations.

[0075] Referring to FIG. 4, method 400 may begin, and at block 405, the application functions of an application and the application requirements for enabling the application functions may be received. For example, application provider 122 may communicate with IAM system 102 via application interface 212 (e.g., API) to define the application functions and their access boundaries, and the application requirements for authorization tokens (e.g., formatting and input requirements) for enabling the application functions. For example, the application requirements may identify the user attributes expected for the application to enable the application functions, and the formatting requirements for authorization tokens for including user attributes expected in a format that may be used by the application to provide suitable permissions and access levels to the user.

[0076] In block 410, one or more authorization policies may be generated according to the application function and application requirements. For example, in some embodiments, the authorization service 226 (e.g., the logic policy engine 302) may generate one or more authorization policies to enable one or more application functions according to the application requirements of those application functions. In some embodiments, the authorization policy may further define an appropriate level of authentication to authorize the user for the corresponding application function.

[0077] In block 415, an authorization hierarchy may be determined according to the access level granted by one or more authorization policies. For example, in some embodiments, the authorization service 226 (e.g., the logic policy engine 302) may direct all of the authorization policies generated for a particular application in multiple levels according to the level of access (e.g., the enabled application function) granted by the authorization policy. Each level may include one or more authorization policies to enable one or more application functions of the application, and may be associated with one or more user attributes expected by the application to enable one or more application functions.

[0078] In block 420, an application profile may be generated that associates one or more user attributes with an authorization hierarchy. For example, in some embodiments, an authorization policy for a particular application may, if it exists, be driven based on particular user attributes that enable the application to provide access to the corresponding application functionality. Thus, an application profile for the application may be generated by the authorization service 226 to map the authorization hierarchy to particular user attributes defined by the application requirements, and the application profile may be used (e.g., by the authentication service 224) to filter all of the user attributes of the user stored in the contact MDM 222 to include only the set of user attributes associated with the application so as to provide appropriate authorization to the user.

[0079] In block 425, one or more authorization policies may be executed in response to one or more attributes or one or more combinations of attributes in the set of user attributes, and method 400 may end. For example, as will be discussed in more detail with reference to FIG. 5, in some embodiments, during user login, the authentication service 224 may query the contact MDM service 222 about the user's attributes according to the identity token received from the identity provider 124, filter the user's attributes according to the application profile for the corresponding application, and identify only the user attributes associated with the corresponding application. The authentication service 224 may generate an application-specific user profile that includes a set of user attributes corresponding only to the user attributes associated with the corresponding application, provide the application-specific user profile to the authorization service 226, and identify one or more authorization hierarchies according to one or more user attributes in the set of user attributes. The authorization service 226 may execute the authorization policies of the identified one or more authorization hierarchies to generate an authorization token that includes the relevant user attributes used by the corresponding application to provide authorization.

[0080] Figure 5 is a flowchart of a method for generating an application-specific user profile to authorize a user, according to one or more embodiments of the present disclosure. For example, method 500 may be performed by authentication service 224 and / or authorization service 226 (e.g., policy engine 242) shown in FIGS. 2 and 3. However, the present disclosure is not limited thereto, and the operations shown in method 500 may be performed by any suitable one or more of the components and elements of the one or more exemplary embodiments described above or any suitable combination of components and elements. Further, the present disclosure is not limited to the sequence or number of operations of method 500 shown in FIG. 5, and may be changed to any desired sequence or number of operations as recognized by those skilled in the art. For example, in some embodiments, the order may vary, or method 500 may include fewer or additional operations.

[0081] Referring to FIG. 5, method 500 may begin, and at block 505, an identity token for a user login to an application may be received. For example, in some embodiments, authentication service 224 may receive an identity token from identity provider 124 corresponding to the user login in the UI / UX of the corresponding application. The identity token may include user identity information (e.g., authentication mechanism), group information associated with the user (e.g., AD group information), and / or the like. In some embodiments, the identity token may further identify the application for which the user is requesting a login.

[0082] In block 510, user attributes associated with the identity token may be retrieved. For example, in some embodiments, the authentication service 224 may query the contact MDM service 222 according to the identity information stored in the identity token to identify all user attributes associated with the user. In block 515, the user attributes may then be filtered according to the application profile of the application to identify a set of user attributes. In block 520, an application-specific user profile including the set of user attributes may be generated. For example, the authentication service 224 may identify the corresponding application profile of the application (or communicate with the authorization service 226 to provide the corresponding application profile), and filter the user attributes retrieved from the contact MDM service 222 to identify a set of user attributes related to the application in order to provide appropriate permissions and access levels to the user. The authentication service 224 may generate an application-specific user profile including the set of user attributes, and provide the application-specific user profile to the authorization service 226 to generate an appropriate authorization token.

[0083] Thus, in some embodiments, in block 525, one or more authorization levels may be identified according to one or more user attributes or one or more combinations of user attributes in the application-specific user profile, and an appropriate authorization token may be generated, and the method 500 may end. For example, as will be discussed in more detail below with reference to FIG. 6, in some embodiments, the authorization service 226 may identify one or more authorization levels based on one or more user attributes or one or more combinations of user attributes in the set of user attributes of the application-specific user profile, and execute the authorization policy of the authorization level to generate an appropriate authorization token.

[0084] FIG. 6 is a flowchart of a method for generating an authorization token according to one or more embodiments of the present disclosure. For example, method 600 may be executed by the authorization service 226 (e.g., policy engine 242) and / or authentication service 224 shown in FIGS. 2 and 3. However, the present disclosure is not limited thereto, and the operations shown in method 600 may be executed by any suitable one or more of the components and elements of the one or more exemplary embodiments described above or any suitable combination of components and elements. Further, the present disclosure is not limited to the sequence or number of operations of method 600 shown in FIG. 6, and may be changed to any desired sequence or number of operations as recognized by those skilled in the art. For example, in some embodiments, the order may vary, or method 600 may include fewer or additional operations.

[0085] Referring to FIG. 6, method 600 may begin, and at block 605, an application-specific user profile including a set of user attributes may be received. For example, in some embodiments, as discussed above, the authentication service 224 may query the contact MDM service 222 according to the identity information of the identity token to retrieve the user attributes of the user, and filter the user attributes according to the application profile of the application to identify a set of user attributes related to the application in order to provide appropriate permissions and access levels to the user, thereby generating an application-specific user profile. The authentication service 224 may provide the application-specific user profile to the authorization service 226.

[0086] In block 610, an authorization hierarchy associated with one or more user attributes in the user attribute set may be identified, and in block 615, an authorization policy associated with the authorization hierarchy may be identified. For example, in some embodiments, the authorization service 226 may identify one or more authorization hierarchies associated with one or more user attributes stored in the user attribute set or one or more combinations of user attributes (e.g., associated), and each of the authorization hierarchies may include one or more authorization policies.

[0087] In some embodiments, in block 620, the authorization policy may then be used to determine whether the authentication mechanism used to authenticate the user is sufficient to grant the permissions and access levels of the authorization policy. If the authentication mechanism is not sufficient (e.g., No in block 620), an additional or different authentication method may be requested in block 625. For example, in some embodiments, the authorization service 226 (e.g., the logic policy engine 302) may communicate with the authentication service 224 to request additional or different authentication of the user based on a different authentication mechanism. The authentication service 224 may communicate with the identity provider 124 to provide an additional or different authentication method based on a different authentication mechanism.

[0088] In block 630, a new identity token may be received. For example, identity provider 124 may generate and provide a new identity token based on different authentication mechanisms used to authenticate the user. The method may then continue in block 620 by determining whether the different authentication mechanism is sufficient. If the different authentication mechanism is sufficient according to the authorization policy or the original authentication mechanism is sufficient (e.g., yes Y in block 620), in block 635, an authorization token may be generated based on the authorization policy. In block 640, the authorization token may be sent and method 600 may end. For example, in some embodiments, authorization service 226 may send the authorization token to identity provider 124, and identity provider 124 may generate a login token suitable for completing the user's login to the application. The login token may include, at least, an authorization token (or authorization token information) including the expected user attributes for the application to provide the appropriate permissions and access levels to the user. In some embodiments, the login token may include information combined from the identity token and the authorization token. Accordingly, the user may log in to the application using the login token, and the application may provide the appropriate permissions and access levels to the user based on the authorization token (or authorization token information) in the login token.

[0089] In some embodiments, method 600 may further include a process of determining event information before sending the authorization token, at least in block 640. For example, in some embodiments, the AI policy engine 306 may receive an event notification from another enterprise subsystem 312 and may modify and / or ignore the permissions and access levels granted by the authorization token generated by the logic policy engine 302. Thus, in some embodiments, the AI policy engine 306 may interrupt method 600 in any suitable process block as needed or desired in accordance with the event notification to modify the authorization threshold and / or timing threshold of the authorization granted to the user.

[0090] FIG. 7 shows an environment of an identity and access management system according to one or more embodiments of the present disclosure. In FIG. 7, elements that are the same as or substantially the same as those described above with reference to FIG. 1 may be denoted with the same reference numerals, and therefore, the redundant description may not be repeated.

[0091] For the sake of illustration, FIG. 7 shows a simplified schematic block diagram of an enterprise environment (e.g., see 100 in FIG. 1). Depending on the implementation of the IAM system 102, the environment shown in FIG. 7 may further include other components and / or systems. For example, in some embodiments, the identity provider 124 shown in FIG. 1 may be further provided. Applications (e.g., via the application provider 122) may be registered with and communicatively connected to the identity provider 124 to provide identity / login services as described above. Further, while the figure shows an application operably connected to the IAM system 102 (e.g., via a communication interface), in some embodiments, the application may communicate and exchange information with the IAM system via the identity provider 124 and / or the application provider 122, similar to the embodiments described above.

[0092] In some embodiments, authorization may be provided to a user based on the user's intent with respect to a particular application function. For example, in some embodiments, a user 104 logged into a first application (e.g., a calling application) App 1 may request (e.g., call) an application function of a second application (e.g., a target application) App 2 from the first application App 1. As an example, the first application App 1 may be a general user portal that shows open ticket items or tasks assigned to the user, and the second application App 2 may be a ticket system that maintains ticket submissions and assigns various ticket items to various users. In this scenario, the first application App 1 may enable the user to view, modify, delete, and / or the like one or more ticket items maintained by the second application App 2 from the first application App 1, such that when the user selects an action (e.g., one of view, modify, delete, and / or the like) from the first application App 1, the user's intent may be known with respect to one or more application functions of the second application App 2 based on the selected action within the first application App 1.

[0093] Thus, in some embodiments, the IAM system 102 may generate an authorization token (or authorization token information) for a user to provide authorization for limited access to one or more application functions of a second application App 2 based on various user attributes, access boundaries of desired application functions of the second application, and / or the like, in addition to the user's intent (e.g., a selected action within the first application App 1). Therefore, rather than authorizing all of the user's permissions and access levels for the second application App 2 within the first application App 1, the IAM system 102 may generate an authorization token to authorize only the desired application functions of the second application App 2 for the user based on a selected action (e.g., intent) within the first application App 1. However, it should be recognized that the embodiments described hereinafter do not prevent the user from directly logging in to the second application App 2. For example, thereby, the user may be authorized at all of the permissions and access levels in the second application App 2 according to the relevant user attributes stored in the contact MDM service 222 as non-exclusively described above.

[0094] In some embodiments, rather than generating an authorization token to authorize all permissions and access levels for a user in a second application App 2 (e.g., based on the application user profile of the second application App 2 as discussed above), the IAM system may further filter the user attributes to include only the attributes required by the target API to authorize a particular application function (e.g., based on the API function profile). Therefore, the authorization token may be generated for the target API based on the filtered attributes, thereby providing only the information required by the target API to authorize a particular application function of the second application App 2 for a user within the first application App 1. Accordingly, the resulting authorization token payload may be further reduced by further reducing the amount of unnecessary information for the second application App 2 to be processed, and the security risk may be further reduced by providing the user with limited authorization to access only the application functions of the second application App 2 required to perform the selected action within the first application App 1.

[0095] More specifically, referring to FIG. 7, a user may, for example, log in to the first application App 1 with all permissions and access levels enabled by the user's user attributes for the first application App 1, according to an authorization token for the first application App 1 generated by the IAM system 102 as described above. The first application App 1 may enable the user to select an action to launch an application function of the second application App 2 from the first application App 1. For example, the first application App 1 may include a link, button, or the like in the first application App 1 that causes the first application App 1 to READ, WRITE, MODIFY, DELETE, and / or the like data stored and / or accessible by the second application App 2.

[0096] In some embodiments, when a user of the user device 104 selects a link, button, or the like in the first application App 1, the first application App 1 may request an authorization token suitable for the IAM system 102 based on the selected action, and to launch one or more application functions of the second application App 2, send a suitable API request 700 (e.g., via the network 106 shown in FIG. 1) to a target API (e.g., App 2 API) of the application provider 122 of the second application App 2 (e.g., App 2 provider). The API request 700 may include a suitable authorization token (or authorization token information) generated by the IAM system 102 such that only the information required by the target API (e.g., App 2 API) is provided to enable only the corresponding application function of the second application App 2 for the user within the first application App 1.

[0097] For example, in some embodiments, when a call is made to a target API (e.g., App 2 API), the calling application (e.g., App 1) may communicate with the IAM system 102 to retrieve information regarding the calling identity, and the IAM system 102 generates a specific authorization token based on the calling identity with only the information required to call and be authorized for the target API. In other words, the authorization token may include only the information required by the target API to authorize access to the corresponding application function. For example, when requesting an authorization token for a target API (e.g., App 2 API), the calling application (e.g., App 1) may provide identity information identifying the calling application and / or user to the IAM system 102, and the IAM system 102 uses the identity information to obtain a fresh token (if necessary) on behalf of the user. The IAM system 102 uses the provided information to retrieve relevant attributes regarding this calling identity (e.g., from the contact MDM service 222) for calling the target API.

[0098] When user attributes for a target API (e.g., App 2 API) are retrieved, the IAM system 102 filters the attributes based on an API-specific profile (e.g., API function profile) for the corresponding application function associated with the target API to generate a target API-specific user profile (e.g., target API profile) for the user of the calling application (e.g., App 1). The target API profile is used to calculate / run the corresponding authorization policy based on the attributes present in the target API profile, whereby a suitable authorization token is generated to authorize only the application functions associated with the target API for the calling application / user. The suitable authorization token is provided to the calling application (e.g., App 1), which will include the authorization token (or authorization token information) within the API request 700 at the time of startup, and the target API may use the authorization token (or authorization token information) to provide a suitable response in accordance with the identified authorization of the calling application / user.

[0099] In some embodiments, the IAM system 102 may further include, or be communicatively coupled to, an API marketplace 702 to enable an application provider 122 to register APIs that the IAM system 102 should understand. In other words, the API marketplace 702 may be a kind of API directory for the IAM system 102, whereby the IAM system 102 may provide appropriate authentication and authorization services for the registered APIs. The figure shows the API marketplace 702 as being separate from the IAM system 102 (e.g., implemented on a separate processor and / or memory from that of the IAM system 102), but the present disclosure is not limited thereto. For example, in other embodiments, the API marketplace 702 may be part of the IAM system 102 (e.g., implemented on the same processor and / or memory as that of the IAM system 102), may be distributed among one or more processors and / or memories of the IAM system 102, or may be implemented separately from and communicatively coupled to the IAM system 102 (e.g., via a LAN, WAN, Internet, cellular network, and / or the like). In some embodiments, the API marketplace 702 may be an API service for small companies and / or the like (e.g., an API service of a target application or the like).

[0100] Application provider 122 may communicate with API marketplace 702 (e.g., communication interface, application interface, and the like) to register various APIs, and may define, for example, application functions associated with each of the registered APIs and their corresponding access boundaries based on business roles, business policies, AD groups, mappings, capabilities, and / or the like. Therefore, when the calling application requests an authorization token for the corresponding application function of the target API, IAM system 102 may use the registered information of the target API to generate a suitable authorization token that will be included in API request 700 to the target API, whereby the target API may authorize only the corresponding application function for the calling application / user based on the attributes in the authorization token.

[0101] For example, application provider 122 may provide various API requirements such as API structures (e.g., formatting and input requirements for the API), associated API application functions (e.g., app function 244), and corresponding application requirements (e.g., app requirement 245) via API marketplace 702, whereby IAM system 102 may use the API requirements to generate an appropriate authorization token that can be understood by the corresponding target API and provide appropriate access to the corresponding application function. Similar to app function 244 described above, the associated API application functions may be provided based on the user's permission and access level, but may correspond to one or more functions of the application that are limited only to those permitted by the corresponding target API. The corresponding application requirements may be the same as or substantially the same as (or similar to) app requirement 245 described above, except that they define the expected input (e.g., user attributes) and formatting requirements for the authorization token for the target API in order to enable only one or more of the associated API application functions.

[0102] In some embodiments, application provider 122 may register, in API marketplace 702, the APIs (e.g., calling-side APIs) that their corresponding applications use to launch the target APIs. For example, various calling-side APIs may be registered to define the target APIs launched by the calling-side APIs and how the corresponding API calls are structured when launching certain ones of the associated API application functions of the target APIs. For example, an API request having a call type formatted as a GET request may correspond to the READ function of the corresponding target API, while an API request having a call type formatted as a POST request may correspond to the WRITE function of the corresponding target API. Thus, the calling-side APIs may be registered in API marketplace 702, whereby IAM system 102 may determine the user's intent regarding the specific application functions associated with the target APIs based on the call type of API requests 702 (e.g., GET, POST, PUT, DELETE, and the like).

[0103] Accordingly, in some embodiments, the application provider 122 of the calling-side application may register the calling-side APIs in API marketplace 702, whereby IAM system 102 may identify the corresponding target APIs and the specific application functions of the target APIs called by the calling-side APIs. In some embodiments, the calling-side application may register the APIs to enable the application functions of the calling-side application to be called by IAM system 102 and / or other applications as needed or desired, and various suitable modifications may be possible as will be understood by those skilled in the art.

[0104] FIG. 8 shows an identity and access management system according to one or more embodiments of the present disclosure. In FIG. 8, elements that are the same as or substantially the same as those described above may be denoted using the same reference numerals, and thus, their redundant description may not be repeated.

[0105] Referring to FIG. 8, in some embodiments, the IAM system 102 may be communicatively connected to a calling application (e.g., App 1) via, for example, a user device 104 (see, e.g., FIG. 7). For example, in some embodiments, the IAM system 102 may include a communication interface 802 for communicating with the calling application App 1 (e.g., via the user device 104). The communication interface 802 may be a separate interface from those of the application interface 212 and the securitization interface 214 (see, e.g., FIG. 2), or at least two of the communication interface 802, the application interface 212, and the securitization interface 214 may be part of the same interface.

[0106] For example, communication interface 802 may be or may include a wired or wireless communication interface (e.g., a jack, an antenna, a transmitter, a receiver, a transceiver, a wire terminal, and / or the like) for performing data communication with IAM system 102. In various embodiments, communication via interface 802 can be direct (e.g., local wired or wireless communication) or can be via network 106 (see, e.g., FIG. 1). For example, interface 802 may include a Wi-Fi® transceiver for communicating via a wireless communication network. In another example, interface 802 may include an Ethernet® card and port for transmitting and receiving data via an Ethernet®-based communication link or network. In another example, interface 802 may include a cellular or mobile phone transceiver. In various embodiments, interface 802 may support various protocols (e.g., TCP / IP, User Datagram Protocol UDP, Hypertext Transfer Protocol HTTP, Internet Message Access Protocol IMAP, Simple Mail Transfer Protocol SMTP, and / or the like) and / or data communication interfaces (e.g., APIs, web services, and / or the like) for facilitating data communication with applications (e.g., user device 104 and / or application provider 122).

[0107] In some embodiments, a calling application (e.g., App 1) may be communicatively connected to an IAM system 102 (e.g., via a communication interface 802) to request an authorization token (or authorization token information) for an application function corresponding to a target API of another application (e.g., App 2). In other embodiments, a calling application (e.g., App 1) may communicate with the IAM system 102 via an identity provider 124 (e.g., see FIG. 1) to request an authorization token (or authorization token information) for an application function corresponding to a target API of another application (e.g., App 2), similar to the login request described above.

[0108] For example, in some embodiments, a calling application may provide a calling API and identity information (e.g., an identity token, a login token, an authorization token, and / or the like) in an API token request to the IAM system 102, whereby the IAM system 102 may generate an authorization token suitable for enabling the corresponding application function of the target API called by the calling application. The IAM system 102 may provide the generated authorization token (or authorization token information) to the calling application, and the calling application may send an API request (e.g., the API request 700 shown in FIG. 7) to the target API. The API request may include the authorization token (or authorization token information) generated by the IAM system 102, whereby the target API may provide the calling application with access to only one or more corresponding application functions based on the authorization token (or authorization token information).

[0109] For example, as shown in FIG. 8, in some embodiments, memory 220 may further include an API service 804 in addition to a contact MDM service 222, an authentication service 224, and an authorization service 226. Services 222, 224, 226, and 804 receive inputs from application provider 122, identity provider 124, calling application (e.g., App 1), and other data sources (e.g., other enterprise systems and subsystems), determine actions for IAM system 102 based on the inputs, generate control signals based on the actions, and are configured to provide the generated control signals to interfaces 212, 214, and 802 for communicating with application provider 122, identity provider 124, and the calling application. The contact MDM service 222, the authentication service 224, and the authorization service 226 may be the same or substantially the same (or similar) as those described above with reference to FIG. 2, and therefore, their redundant descriptions may not be repeated.

[0110] Although FIG. 8 shows that each of the contact MDM service 222, the authentication service 224, the authorization service 226, and the API service 804 is part of the same processing circuit 216, the present disclosure is not limited thereto. For example, each of services 222, 224, 226, and 804 may be implemented on one or more internal processing circuits with respect to IAM system 102, or may be implemented on one or more external processing circuits as part of a cloud-based computing system. Further, although FIG. 8 shows the API service 804 as a separate service from the authentication service 224 and the authorization service 226 for illustration purposes, it should be recognized that the API service 804 (or a suitable portion thereof) may be part of the authentication service 224 and / or the authorization service 226 in some embodiments.

[0111] In summary, the API service 804 may register an application that utilizes one or more APIs registered in the API marketplace 702. The API service 804 may map each of the registered APIs in the API marketplace 702 to corresponding application functions, and register an API function profile (e.g., generated by the authorization service 226) for each of the corresponding application functions of each of the registered APIs. In response to an API token request, the API function profile may be used to filter attributes (e.g., stored in the contact MDM service 222) to generate a target API profile for the corresponding application function of the target API. The target API profile may include only the attributes required by the target API to enable the corresponding application function for the user in the calling application, and may be used (e.g., by the authorization service 226) to execute one or more API authorization policies to generate an authorization token suitable for authorizing only the corresponding application function by the target API.

[0112] For example, the API service 804 may receive an API token request (e.g., from a calling application or via the identity provider 124), and may identify the identity information and the calling API from the API token request. The API service 804 may determine whether the calling application is authorized to call the corresponding target API associated with the calling API. The API service 804 (or via the authentication service 224) may retrieve attributes associated with the identity information from the contact MDM service 222, filter the attributes based on the API function profile of the corresponding application function of the target API, and generate a target API profile that includes only the attributes required by the target API to enable the corresponding application function. The API service 804 may generate an appropriate authorization token in response to the API token request and communicate with the authorization service 226 to execute one or more API authorization policies based on the target API profile to provide the authorization token to the calling application. The calling application may include the authorization token (or authorization token information) in an API request to the target API to activate the corresponding application function of the target application, whereby the target API may provide an appropriate response (e.g., granting or denying access) based on the attributes stored in the authorization token (or authorization token information).

[0113] More specifically, in some embodiments, the API service 804 may include a registered application 806, a registered API function profile 808, and a target API profile generator 810. FIG. 8 shows the registered application 806, the registered API function profile 808, and the target API profile generator 810 as part of the API service 804, but in some embodiments, it should be recognized that at least some of the registered application 806, the registered API function profile 808, and the target API profile generator 810 may be part of the API marketplace 702, the authentication service 224, and / or the authorization service 226.

[0114] The registered application 806 may be a front door for establishing API governance and authorization boundaries for managed and trusted applications (e.g., App 1, App 2, and the like). The registered application 806 may include registration information associated with each of the registered applications (or application providers 122) for utilizing one or more APIs registered in the API marketplace 702. For example, each of the calling application (e.g., App 1) and the target application (e.g., App 2) may be registered with the registered application 806. The registration information may include, for example, an application identifier, API permission information that allows the application to make calls, mapping information of the registered APIs, and / or the like. The registration information may be used by the API service 804 to determine whether the calling application is authorized to call a particular target API and the portions of authentication and authorization required for the target API call.

[0115] The API service 804 may map each of the registered APIs to corresponding task or application functions. For example, if the registered API is a target API, the API service 804 may map the target API to the corresponding application function. If the registered API is a calling-side API, the calling-side API may be mapped to the corresponding target API, whereby the corresponding application function mapped to the target API may be identified. The API service 804 may register, in the registered API function profile 808, a corresponding API function profile for each of the registered APIs that defines all of the user and / or application attributes required by the target API to enable the corresponding application function for the calling-side application. For example, the registered API function profile 808 may include various call types (e.g., GET, POST, and the like) corresponding to various application functions permitted by the target API, and information corresponding to how the call type of the API call is mapped to the various application functions.

[0116] For example, in some embodiments, the API function profile may be generated by the authorization service 226 for the registered API based on the application functions and API requirements for the registered API defined by the application provider 122, similar to the application profile generated by the policy engine 242 as described above. However, unlike the case of the application profile described above, instead of enabling the various application functions of the corresponding application based on all of the various sets and combinations of user attribute types that may exist, the API function profile may define only the attributes used by the corresponding target API to enable the application function of the target API that the calling-side application is invoking.

[0117] The target API profile generator 810 may filter attributes (e.g., stored in the contact MDM service 222) and use the API function profile of the target API corresponding to generate a target API profile. For example, in some embodiments, in response to an API token request, the target API profile generator 810 may parse the identity information (e.g., identity token) stored in the API token request. The target API profile generator 810 may query the contact MDM service 222 based on the identity information (e.g., directly or via the authentication service 224) to retrieve user attributes. The target API profile generator 810 may identify the target API mapped to the calling-side API in the API token request, identify the registered API function profile for the application function associated with the identified target API (e.g., in the registered API function profile 808), and filter the attributes according to the registered API function profile for the identified target API. Therefore, the target API profile may include only the relevant attributes required to enable the corresponding application function by the target API. The target API profile may then identify the corresponding API authorization policy and be used (e.g., by the authorization service 226) to generate an authorization token suitable for enabling the corresponding application function by the target API.

[0118] In some embodiments, the authorization service 226 may generate an API authorization policy according to the associated API application functions and corresponding application requirements defined by the application provider 122 when registering the API, and execute an appropriate one of the API authorization policies to generate an authorization token according to the set of user attributes of the user stored in the target API profile. For example, in some embodiments, the policy engine 242 of the authorization service 226 may generate various API authorization policies according to the associated API application functions and corresponding application requirements defined by the application provider 122, generate a corresponding API function profile for each of the registered APIs, and associate (e.g., link or map) each of the API authorization policies with various expected user attributes used to execute the corresponding API authorization policy when generating the authorization token. The generated API function profiles may be registered in the registered API function profiles 808 and used by the target API profile generator 810 (or the authentication service 224) to filter the attributes for the identity information stored in the API request to generate a suitable target API profile.

[0119] For example, in some embodiments, the polyengine 242 may compute / generate an API authorization policy for each of the registered APIs to generate an appropriate authorization token for the user to access a specific application function enabled by the identified target API. The API authorization policy may be computed / generated based on the associated API application functions and corresponding application requirements defined by the application provider 122, and the API authorization policy may be executed to generate an authorization token based on the specific user attributes and contact information (e.g., a set of user attributes) of the user stored in the target API profile for the user. Similar to the authorization policy described above with reference to FIG. 3, the API authorization policy may be hierarchical and / or each API authorization policy may be associated with a corresponding target API (or corresponding API application function), such that when an API token request is received, an appropriate API authorization policy is identified and executed to generate an appropriate authorization token for the identified target API.

[0120] The associated API application functions may correspond to various functions of the application that can be enabled by the target API based on the user's permissions and access levels, and the corresponding application requirements may define the expected inputs (e.g., user attributes) and formatting requirements of the authorization token to enable the API application functions associated by the target API. Therefore, the associated API application functions may define the access boundaries of the application that can be accessed via the target API, and the corresponding application requirements may define the specific business roles, business goals, business policies, mappings, and / or the like used by the target API to provide the permissions and access levels required to access a specific API application function of the corresponding application.

[0121] Accordingly, when an API token request is received, the target API profile generator 810 (or the authentication service 224) may use the API function profile for the identified target API to generate a target API profile by filtering the user attributes stored in the contact MDM service 222 according to the user attribute types used by the identified target API to provide access to the corresponding application function. The target API profile may include only the user attributes (e.g., a set of user attributes) of the user associated with the target API when determining whether the calling application / user should be granted access to the API application function associated therewith. The target API profile generator 810 (or the authentication service 224) may provide the target API profile to the authorization service 226 to select and execute one or more corresponding API authorization policies to generate an appropriate authorization token according to the set of user attributes in the target API profile. The generated authorization token may be provided to the calling application in response to the API token request, and the calling application may include the authorization token in the API request to the target API, whereby the target API may enable the corresponding application function for the calling application / user according to the authorization token.

[0122] FIG. 9 is a flowchart of a method for generating an API authorization policy according to one or more embodiments of the present disclosure. For example, method 900 may be executed by an authorization service 226 (e.g., a policy engine 242) as described above. However, the present disclosure is not limited thereto, and the operations shown in method 900 may be executed by any suitable one or combination of components and elements of the one or more exemplary embodiments described above. Further, the present disclosure is not limited to the sequence or number of operations of method 900 shown in FIG. 9, and may be changed to any desired sequence or number of operations as recognized by those skilled in the art. For example, in some embodiments, the order may vary, or method 900 may include fewer or additional operations.

[0123] Referring to FIG. 9, method 900 may begin, and at block 905, API requirements for a registered API may be received, including at least application functions associated with the API and application requirements for enabling the application functions. For example, application provider 122 of a target API (e.g., App 2 API) may communicate with IAM system 102 via API marketplace 702 to define the API requirements of the target API registered with API marketplace 702. The API requirements may include at least application functions (e.g., associated API application functions) and their access boundaries, and application requirements for authorization tokens (e.g., corresponding formatting and input requirements) that can be understood by the target API to enable the application functions for the calling application / user. For example, the application requirements may identify expected user attributes for the target API to enable the application functions of the application for the calling application / user, and formatting requirements for authorization tokens to include expected user attributes in a format that can be used by the application to provide suitable access to the application functions of the application for the calling application / user via the target API. In some embodiments, the API requirements may further include an API structure (e.g., formatting and input requirements for the API) so that the IAM system 102 understands how an API request can be constructed to include information (e.g., an authorization token or authorization token information) required by the target API in a suitable format in the API request to enable the corresponding application functions for the calling application / user.

[0124] In block 910, one or more API authorization policies may be generated according to the received API requirements. For example, in some embodiments, the authorization service 226 (e.g., the logic policy engine 302) may generate one or more API authorization policies based at least on the application function and application requirements. When executed, the API authorization policy may generate an appropriate authorization token for the target API to enable the application function for the calling application / user when authorized.

[0125] In block 915, an API application function profile (e.g., an API function profile) may be generated that associates one or more user attribute types required by one or more API authorization policies. For example, the API function profile may define all of the user attribute types required by the one or more generated API authorization policies to generate an authorization token for the target API. The API function profile may be used by the contact MDM service 222 to filter the user attributes stored thereby to include only those attributes required to execute the one or more authorization policies associated with the API function profile to generate an authorization token for the target API. Thus, the API function profile for an API may be generated by the authorization service 226 to map the API authorization policy to specific user attributes defined by the application requirements, and the API function profile may be used (e.g., by the authentication service 224 or the target API profile generator 810) to filter all of the attributes of the calling application / user stored by the contact MDM service 222 to include only those attributes associated with the target API (e.g., in the target API profile) to provide access to the corresponding application function of the corresponding application to the calling application / user.

[0126] In block 920, an application profile for the API may be registered, and method 900 may end. For example, the API function profile may be registered by or with an API service 804 (e.g., in the registered API function profile 808) and associated with the registered API. As will be discussed in more detail below, in response to an API token request, the API function profile may be used (e.g., by the target API profile generator 810 and / or the authentication service 224) to filter attributes of identity information for the calling application / user stored in the contact MDM service 222, whereby the filtered attributes (e.g., in the corresponding target API profile) are used to execute only one or more API authorization policies associated with the API function profile to generate an authorization token that authorizes only the corresponding application functions by the target API.

[0127] FIG. 10 is a flowchart of a method for generating an authorization token in response to an API token request, according to one or more embodiments of the present disclosure. For example, method 1000 may be executed by the IAM system 102 described above (e.g., the authentication service 224, the authorization service 226, and / or the API service 804). However, the present disclosure is not limited thereto, and the operations shown in method 1000 may be executed by any suitable one or combination of components and elements of the one or more exemplary embodiments described above. Further, the present disclosure is not limited to the sequence or number of operations of method 1000 shown in FIG. 10, and may be changed to any desired sequence or number of operations as recognized by those skilled in the art. For example, in some embodiments, the order may vary, or method 1000 may include fewer or additional operations.

[0128] Referring to FIG. 10, method 1000 may begin, and at block 1005, an API token request including identity information and a calling-side API may be received. For example, in some embodiments, API service 804 (e.g., target API profile generator 810) and / or authentication service 224 may receive the API token request from a calling-side application (e.g., App 1) or via an identity provider 124 communicatively connected to the calling-side application. The identity information may include, for example, an identity token including an authentication mechanism used to identify the user, group information (e.g., AD group information) associated with the user, and / or the like.

[0129] At block 1010, user attributes associated with the identity information may be retrieved. For example, in some embodiments, target API profile generator 810 (or authentication service 224) may query contact MDM service 222 according to the identity information stored in the API token request to identify all attributes associated with the calling-side application / user. These attributes may then be filtered according to the API function profile of the target API to generate a corresponding target API profile (see, for example, block 1020). For example, in some embodiments, at block 1015, the target API called by the calling-side API may be identified, and the corresponding API function profile registered for the identified target API (e.g., in registered API function profile 808) may be identified.

[0130] Accordingly, in block 1020, attributes (retrieved, for example, in block 1010) may be filtered according to an API function profile to generate a target API profile. For example, a target API profile generator 810 (or authentication service 224) may retrieve a corresponding API function profile (from, for example, a registered API function profile 808), filter the attributes retrieved from the contact MDM service 222, and generate a target API profile that includes only the attributes necessary to enable the corresponding application functions by the target API. The target API profile may be provided to an authorization service 226 to generate an appropriate authorization token for the target API.

[0131] In block 1025, one or more API authorization policies associated with the API function profile may be identified. For example, in some embodiments, a target API profile generator 810 (or authentication service 224) may provide the target API profile to an authorization service 226, and the authorization service 226 may identify one or more API authorization policies to be computed / executed to generate an appropriate authorization token for enabling the corresponding application functions by the target API (based on, for example, the corresponding target API profile or the corresponding API function profile).

[0132] In some embodiments, one or more API authorization policies may then be used to determine whether the authentication mechanism used to authenticate the calling application / user is sufficient to grant access to the application functions associated therewith, similar to blocks 620-630 described above with reference to FIG. 6, whereby a new identity token may be requested (from, for example, identity provider 124) based on the different authentication mechanisms used, although the present disclosure is not limited thereto.

[0133] In block 1030, an authorization token may be generated based on one or more API authorization policies and attributes stored in the target API profile. In block 1035, the authorization token may be sent and method 1000 may end. For example, in some embodiments, the authorization service 226 (or API service 804) may send the authorization token to the calling application (or via the identity provider 124), and the calling application may include the authorization token in an API request to the target API, whereby the target API may provide authorization to the corresponding application function according to the attributes stored in the authorization token. Thus, the calling application (e.g., App 1) may be provided access only to the application functions of the target application (e.g., App 2) corresponding to the target API (e.g., App 2 API) based on the information (e.g., attributes) stored in the authorization token, regardless of other permissions and access levels of the user within the target application.

[0134] In the drawings, the relative sizes of elements, layers, and regions may be exaggerated and / or simplified for clarity. Spatially relative terms such as "beneath," "below," "lower," "under," "above," "upper," and the like may be used herein for ease of explanation to describe the relationship of one element or feature to another element or feature as shown in the figures. It will be understood that the spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation shown in the figures. For example, if the device in the figures is inverted, an element described as "beneath" or "below" or "under" another element or feature will be oriented "above" the other element or feature. Thus, the exemplary terms "below" and "under" can encompass both an above and a below orientation. The device may be otherwise oriented (e.g., rotated 90 degrees or at some other orientation), and the spatially relative descriptors used herein should be interpreted accordingly.

[0135] The terms "first," "second," "third," etc. may be used herein to describe various elements, components, regions, layers, and / or sections, but it will be understood that these elements, components, regions, layers, and / or sections are not to be limited by these terms. These terms are used to distinguish one element, component, region, layer, or section from another. Thus, a first element, component, region, layer, or section described below may be referred to as a second element, component, region, layer, or section without departing from the spirit and scope of the present disclosure.

[0136] When an element or layer is said to be "on," "connected to," or "coupled to" another element or layer, it will be understood that it can be directly on, connected to, or coupled to the other element or layer, or that one or more intervening elements or layers may be present. Similarly, when a layer, area, or element is said to be "electrically connected" to another layer, area, or element, it may be directly electrically connected to the other layer, area, or element and / or may be indirectly electrically connected through one or more intervening layers, areas, or elements therebetween. Additionally, when an element or layer is said to be "between" two elements or layers, it will be understood that it can be the only element or layer directly between the two elements or layers, or that one or more intervening elements or layers may be present.

[0137] Where specific embodiments can be implemented differently, the particular process order may be different than that described. For example, two consecutively described processes may be performed simultaneously or substantially simultaneously, or in an order opposite to that described.

[0138] The terms used in this specification are for the purpose of describing particular embodiments and are not intended to limit the disclosure. As used in this specification, the singular forms "a" and "an" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The terms "comprises," "comprising," "includes," "including," "has," "have," and "having," when used in this specification, specify the presence of the recited feature, integer, step, operation, element, and / or component, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used in this specification, the term "and / or" includes any and all combinations of one or more of the associated listed items. For example, the expression "A and / or B" means A, B, or A and B. Expressions such as "at least one of" following a list of elements change the entire list of elements and do not change the individual elements of the list. For example, the expression "at least one of a, b, or c" means only a, only b, only c, both a and b, both a and c, both b and c, all of a, b, and c, or variations thereof.

[0139] As used herein, the terms "substantially," "about," and the like are used as terms of approximation and not of degree, and are intended to account for inherent variations in measured or calculated values recognized by those of ordinary skill in the art. Further, the use of "may" when describing embodiments of the present disclosure refers to "one or more embodiments of the present disclosure." As used herein, the terms "use," "using," and "used" may each be considered synonymous with the terms "utilize," "utilizing," and "utilized," respectively.

[0140] The electronic or electrical devices and / or any other associated devices or components according to the embodiments of the present disclosure described herein may be implemented using any suitable hardware, firmware (e.g., application specific integrated circuit), software, or a combination of software, firmware, and hardware. For example, various components of these devices may be formed on one integrated circuit (IC) chip or on separate IC chips. Further, various components of these devices may be implemented on a flexible printed circuit film, a tape carrier package (TCP), a printed circuit board (PCB), or may be formed on one substrate. Further, various components of these devices may be a process or thread executed on one or more processors in one or more computing devices that execute computer program instructions to perform various functions described herein and interact with other system components. The computer program instructions may be stored in a memory implemented in a computing device using a standard memory device such as random access memory (RAM). The computer program instructions may also be stored on other non-transitory computer-readable media such as, for example, a CD-ROM, a flash drive, or the like. Also, those skilled in the art should recognize that, without departing from the spirit and scope of the exemplary embodiments of the present disclosure, the functions of various computing devices may be combined or integrated into a single computing device, or the functions of a particular computing device may be distributed across one or more other computing devices.

[0141] Unless otherwise defined, all terms (including technical and scientific terms) used herein shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Terms such as those defined in commonly used dictionaries shall be interpreted to have a meaning consistent with the meaning in the context of the relevant art and / or this specification, and should not be interpreted in an idealized or overly formal sense unless explicitly so defined herein.

[0142] Although several embodiments have been described, those of ordinary skill in the art will readily recognize that various changes are possible in the embodiments without departing from the spirit and scope of the disclosure. It should be understood that the description of features or aspects within each embodiment should typically be considered available for other similar features or aspects in other embodiments unless otherwise stated. Therefore, as will be apparent to those of ordinary skill in the art, the characteristics, features, and / or elements described in connection with a particular embodiment may be used alone or in combination with the features, characteristics, and / or elements described in connection with other embodiments, unless specifically shown otherwise. Accordingly, the foregoing is illustrative of various exemplary embodiments and should not be construed as limited to the specific embodiments disclosed herein, and various changes to the disclosed embodiments and other exemplary embodiments are intended to be included within the spirit and scope of the disclosure as defined in the appended claims and their equivalents.

Claims

1. At least one processor; and When executed by the at least one processor, cause the processor to Receive an API token request for an authorization token and authorize an application function associated with a target API of the application; Determine identity information from the API token request; Derive attributes associated with the identity information; Identify the target API and an API function profile associated with the target API for the application function; Filter the attributes associated with the identity information based on the API function profile; Generate the authorization token according to the filtered attributes; and Send the authorization token in response to the API token request A memory having instructions to cause the above An identity and access management system comprising.

2. The identity and access management system according to claim 1, wherein the attributes are retrieved from a master data management store configured to store various attributes of various applications and users.

3. The instructions cause the at least one processor to Identify one or more API authorization policies based on the API function profile; and Execute the one or more API authorization policies based on the filtered attributes to generate the authorization token The identity and access management system according to claim 1, further causing the above.

4. The identity and access management system according to claim 3, wherein the API authorization policy enables only the application function associated with the target API from among a plurality of application functions associated with the application of the target API.

5. The instructions cause the at least one processor to A procedure for receiving API requirements registered in an API marketplace for the target API, the API requirements including at least the application function associated with the target API and application requirements for the authorization token for enabling the application function by the target API; A procedure for generating the API authorization policy based on the application function and the application requirements; A procedure for generating the API function profile for the target API based on the API authorization policy; and A procedure for associating the API function profile with the target API The identity and access management system according to claim 4, further performing.

6. The identity and access management system according to claim 5, wherein the API function profile includes a plurality of attribute types to be included in the authorization token generated for the target API.

7. The identity and access management system according to any one of claims 1 to 6, wherein the authorization token enables only the application function associated with the target API from among a plurality of application functions associated with the application of the target API.

8. Receiving an API token request for an authorization token and authorizing an application function associated with the target API of the application; Determining identity information from the API token request; Searching for attributes associated with the identity information; Identifying the target API and the API function profile associated with the target API for the application function; Filtering the attributes associated with the identity information based on the API function profile; Generating the authorization token according to the filtered attributes; and Sending the authorization token in response to the API token request A method comprising.

9. The method according to claim 8, wherein the attributes are retrieved from a master data management store configured to store various attributes of various applications and users.

10. identifying one or more API authorization policies based on the API function profile; and executing the one or more API authorization policies based on the filtered attributes to generate the authorization token The method according to claim 8, further comprising.

11. The method according to claim 10, wherein the API authorization policy enables only the application functions associated with the target API from among a plurality of application functions associated with the application of the target API.

12. receiving API requirements registered in an API marketplace for the target API, the API requirements including at least the application functions associated with the target API and application requirements for the authorization token for enabling the application functions by the target API; generating the API authorization policy based on the application functions and the application requirements; generating the API function profile for the target API based on the API authorization policy; and associating the API function profile with the target API The method according to claim 11, further comprising.

13. The method according to claim 12, wherein the API function profile includes a plurality of attribute types that will be included in the authorization token generated for the target API.

14. The method according to any one of claims 8 to 13, wherein the authorization token enables only the application functions associated with the target API from among a plurality of application functions associated with the application of the target API.

15. at least one processor; and when executed by the at least one processor, the processor is caused to receive an API token request for an authorization token and authorize application functions associated with a target API of an application; A procedure for receiving API requirements registered in an API marketplace for the target API, the API requirements including at least the application function associated with the target API and application requirements for the authorization token for enabling the application function by the target API; A procedure for determining identity information from the API token request; A procedure for retrieving attributes associated with the identity information; A procedure for identifying an API function profile associated with the target API for the target API and the application function; A procedure for filtering the attributes associated with the identity information based on the API function profile; A procedure for generating the authorization token according to the filtered attributes; and A procedure for sending the authorization token in response to the API token request A memory having instructions for causing the above to be performed An identity and access management system comprising the same.

16. The identity and access management system according to claim 15, wherein the attributes are retrieved from a master data management store configured to store various attributes of various applications and users.

17. The instructions cause the at least one processor to A procedure for identifying one or more API authorization policies based on the API function profile; and A procedure for executing the one or more API authorization policies based on the filtered attributes so as to generate the authorization token The identity and access management system according to claim 15 or 16, which further causes the above to be performed.

18. The identity and access management system according to claim 17, wherein the API authorization policy enables only the application function associated with the target API from among a plurality of application functions associated with the application of the target API.

19. The instructions cause the at least one processor to A procedure for generating the API authorization policy based on the application function and the application requirements; A procedure for generating the API function profile for the target API based on the API authorization policy; and Procedure for associating the API function profile with the target API The identity and access management system according to claim 18, further causing the procedure to be performed.

20. The identity and access management system according to claim 19, wherein the API function profile includes a plurality of attribute types that will be included in the authorization token generated for the target API.

Images