METHOD AND DEVICE FOR ISSUING A CERTIFICATE OF AUTHORIZATION FOR AN INCIDENT AREA NETWORK

Abstract

Identity server that features: an electronic processor configured to do the following: receive a credential issued by an agency, wherein the credential issued by the agency includes attributes that specify the authenticity, authority, rights, or a combination thereof, of a user's device; receive an initial set of attributes from the authorization certificate issued by the agency, Assign the first set of attributes to a scope of a computer-based service that is available through an IAN (incident area network). Generate an incident-issued credential for the IAN that includes the scope of the computer-based service available through the IAN, and Issue the user device authorization certificate issued for the incident.

Description

BACKGROUND OF THE INVENTION

[0001] Identity management generally refers to managing the authentication, authorization, and rights of users and user devices within a computer environment. A computer environment can, for example, include a backend infrastructure that controls which users and user devices are permitted to access services available within the computer environment and what rights such user devices have when accessing those services. A system is already known from US 2005 / 0017070 A1, which allows for the on-site issuance of physical identification cards to regulate physical access to an incident site. Furthermore, other systems or procedures relating to rights management are known from US 2008 / 0317218 A1, US 9,332,002 B1, and DE 601 32 334 T2.

[0002] During a public safety incident, a computing environment may be used to provide services to the public safety personnel handling the incident. This computing environment may be referred to as an Incident Area Network (IAN). An IAN can support users and user devices assigned to many different departments, and the number of users and user devices requiring access to the IAN can change rapidly. To authenticate and authorize these users and user devices, the IAN would typically require access to the backend infrastructure for each department. However, in many situations, an IAN operates in a segregated mode, where the network does not have access to other computing environments.Furthermore, duplicating the backend infrastructure of the Incident Area Network may not be feasible due to time, resource, and security constraints. Therefore, authenticating and authorizing users and user devices can pose a challenge for the Incident Area Network. BRIEF DESCRIPTION OF THE DIFFERENT VIEWS OF THE DRAWINGS

[0003] The accompanying figures, in which the same reference numerals refer to identical or functionally similar elements through the separate views, are included in the specification together with the following detailed description, and they form a part thereof, and they serve to further illustrate embodiments of concepts that include the claimed invention, and they explain various principles and advantages of these embodiments. Fig. Figure 1 is a block diagram of a system for performing identity management in an incident area, according to some embodiments. Fig. Figure 2 is a block diagram of an identity server connected to the Incident Area Network of Fig. 1 communicates, according to some embodiments. Fig. Figure 3 is a flowchart of a procedure for issuing an authorization certificate for the Incident Area Network of Fig. 1 with the identity server of Fig. 2, according to some embodiments. Fig. Figure 4 illustrates an example of an assignment scheme, according to some embodiments. Fig. 5 is a flowchart that illustrates communication between the identity server of Fig. 2, a user device and an application server illustrated, according to some embodiments. Fig. 6 is a block diagram of the Incident Area Network of Fig. 1, which includes an attribute provider, according to some embodiments. Fig. 7 is a flowchart that shows communication between the identity server of Fig. 2, a user device, an application server, and the attribute provider of Fig. Figure 6 illustrates some embodiments.

[0004] Experts will recognize that elements in the figures are illustrated for the sake of simplicity and clarity and are not necessarily drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated compared to other elements to help improve the understanding of embodiments of the present invention.

[0005] Where appropriate, the apparatus and process components have been represented by conventional symbols in the drawings, showing only those specific details essential for understanding the embodiments of the present invention, so as not to obscure the disclosure with details that would be readily apparent to those skilled in the art who benefit from this description. DETAILED DESCRIPTION OF THE INVENTION

[0006] One embodiment comprises an identity server including an electronic processor configured to receive an agency-issued credential and retrieve an initial set of attributes from that credential. The electronic processor is also configured to map this initial set of attributes to a scope of a computer-based service available through an incident area network (IAN). Furthermore, the electronic processor is configured to generate an incident-issued credential for the incident area network, encompassing the scope of the computer-based service available through the IAN, and to issue the incident-issued credential to the user device.

[0007] Another embodiment provides an identity server comprising an electronic processor configured to receive an authorization certificate issued by an agency, wherein the authorization certificate issued by the agency includes attributes specifying the authenticity, authority, rights, or a combination thereof, of a user device of a user, and retrieves a first set of attributes from the authorization certificate issued by the agency.The electronic processor is also configured to map the first set of attributes to a second set of attributes, based on the context of an incident associated with an Incident Area Network (IAN). The second set of attributes specifies the authenticity, authority, rights, or a combination thereof, of the user's device to access computer-based services available through the IAN. The electronic processor is further configured to generate an incident-issued credential for the Incident Area Network associated with the incident, comprising the second set of attributes, and to issue the user device credential for the incident.

[0008] Another embodiment provides a method for issuing an authorization certificate issued for an incident for an Incident Area Network, including receiving, with an identity server, an authorization certificate issued by an agency, wherein the authorization certificate issued by the agency includes attributes that specify the authenticity, authority, rights, or a combination thereof, of a user device of a user.The procedure also includes retrieving, using the identity server, a first set of attributes from the credential issued by a department and mapping the first set of attributes to a second set of attributes, based on the context of an incident to which the Incident Area Network is associated. The second set of attributes specifies the authenticity, authority, rights, or a combination thereof, of the user's device to access computer-based services available through the IAN. The procedure further includes generating the incident-issued credential for the Incident Area Network, based on the second set of attributes, and issuing, using the identity server, this incident-issued credential to the user's device.

[0009] Fig. Figure 1 is a block diagram of a System 100 for performing identity management for an incident area, according to one embodiment. The System 100 may include an Incident Identity Server 110, an Incident Application Server 120, and a User Device 130, which communicate via an Incident Area Network 140. Fig. Figure 1 illustrates only one exemplary embodiment of System 100, and System 100 may be configured differently from that shown in Figure 1. Fig. The system shown in Figure 100 may differ in that it includes additional or fewer components. For example, a plurality of incident identity servers (110), a plurality of incident application servers (120), a plurality of user devices (130), or a combination thereof may communicate over the Incident Area Network (140).

[0010] The Incident Area Network 140 can be a wired or wireless communication network, such as a cellular network, an LMR network (LMR = land mobile radio), or similar. Parts of the Incident Area Network 140 can be accessed via a wide area network, such as the internet, or a local area network, such as Bluetooth. ® Incident Area Network 140 can be implemented as a network, or Wi-Fi, and combinations or derivatives thereof. Organizations such as public safety organizations can use it to provide services to users associated with an incident, such as a public safety incident.

[0011] The incident application server 120 hosts one or more computer-based services, such as software applications and APIs (application programming interfaces). For example, the incident application server 120 might be an email server that provides an email application to the user of the device 130. In other embodiments, the incident application server 120 hosts a database that can be accessed through an API. In other embodiments, the incident application server 120 hosts a website that provides web pages. In some embodiments, the incident application server 120 hosts, for example, a collection of REST-based (REST = representation state transfer programming paradigm for distributed systems) microservices that are called by the user device 130.In some embodiments, the incident application server 120 can also communicate with a second application server. In some embodiments, the incident application server 120 includes a server that provides application services and at least one of the following services: a proxy, a reverse proxy, a firewall, an API gateway, and a PIP (policy enforcement point / logical instance on a server that governs access control policies). In these embodiments, the proxy, the reverse proxy, the firewall, the API gateway, and the PIP can receive application requests from the user device 130 and make an appropriate access control decision before forwarding the request to the server that provides the application services.

[0012] The user device 130 accesses the computer-based services hosted by the incident application server 120 via the Incident Area Network 140. The user device 130 can be a handheld device, such as a mobile phone, smartphone, tablet computer, two-way radio, smartwatch, or other wearable device configured to communicate over the Incident Area Network 140. In some embodiments, the user device 130 might be, for example, a handheld cellular phone carried by public safety personnel, such as a police officer. Alternatively, the user device 130 can be a computer device, such as a personal computer, laptop computer, tablet computer, and the like. In some embodiments, the user device 130 might be, for example, a laptop computer installed in a police car.Accordingly, the user device 130 can be any type of device capable of communicating via the Incident Area Network 140.

[0013] The Incident Identity Server 110 performs the identity management functions for the Incident Area Network 140. The Incident Identity Server 110 may be located at the incident associated with the Incident Area Network 140. As described in more detail below, the Incident Identity Server 110 authenticates and authorizes users and user devices accessing the Incident Area Network 140 and issues credentials for use with the Incident Area Network 140. As used herein, the term "credence" includes tokens, statements, digital certificates, cookies, certifications, passwords, usernames, keys, and other objects issued to a user or user device that specify the authenticity, authority, rights, or a combination thereof of the user or user device.In some implementations, the Incident Identity Server 110 issues credentials using a standard identity management mechanism, such as SAML (SAML = security assertion markup language / XML framework for exchanging authentication and authorization information), OAuth, OpenID, and the like.

[0014] Fig. Figure 2 is a block diagram of the Incident Identity Server 110, according to one embodiment. As shown in Fig. As shown in Figure 2, the incident identity server 110 comprises an electronic processor 210 (for example, a microprocessor, an ASIC (application-specific integrated circuit), or another suitable electronic device), a memory 220 (for example, a non-volatile, computer-readable storage medium), and a transceiver 230. The electronic processor 210, the memory 220, and the transceiver 230 communicate via one or more communication lines or buses, such as a communication bus 240. The incident identity server 110 can, in configurations differing from that shown in Figure 2, Fig. The incident identity server 110 shown in Figure 2 may differ, having additional or fewer components. In some embodiments, the incident identity server 110 also performs additional functionality beyond that described here. Similarly, the functionality provided by the incident identity server 110 through the execution of instructions by the electronic processor 210 may be distributed among several electronic processors contained within the incident identity server 110 or other devices. Accordingly, the functionality described here as being provided by the electronic processor 210 may be performed by one or more electronic processors located within or outside the incident identity server 110.

[0015] The electronic processor 210 executes instructions stored in the memory 220 to perform the identity management functions. In particular, the electronic processor 210 executes instructions to perform the function stored in Fig. The procedures described in section 3 are to be carried out. The transceiver 230 communicates via the Incident Area Network 140. In some embodiments, the transceiver 230, for example, sends and receives wireless data via the Incident Area Network 140. In particular, the transceiver 230 can exchange data with the user device 130, with the incident application server 120, or with both, that is, receive and send data. In other embodiments, the incident identity server 110, instead of using the transceiver 230, can include separate components for sending and receiving, for example, a transmitter and a receiver. In some embodiments, the transceiver 230 communicates with communication networks other than the Incident Area Network 140.For example, in some embodiments, the Incident Identity Server 110 includes a plurality of transceivers to communicate with a plurality of communication networks, including the Incident Area Network 140.

[0016] Before or after being placed into System 100, a certificate of authorization issued by a department can be issued to the User Device 130. For example, the User Device 130 can provide a department identity server with identification information of a user operating the User Device 130 (such as a username or password), identification information of the User Device 130 itself (such as a unique serial number, model number, data manipulation capabilities, and the like), or a combination thereof.The agency identity server verifies the identification information (for example, by accessing backend infrastructure such as a database of authorized users, user devices, or combinations thereof). Once the identification information is verified, the agency identity server issues an agency-issued credential to user device 130, such as a digital certificate (an X.509 digital certificate), a token, or the like. User device 130 stores the credential in local memory. In some implementations, the agency-issued credential is digitally signed by the agency identity server, which, as described below, allows other devices to verify the credential.Digitally signing an authorization certificate also prevents forgery because the signature can only be reproduced using confidential data from the agency's identity server, such as a private encryption key. In some versions, the authorization certificate issued by the agency may also include an expiration date.

[0017] For example, in the public safety industry, an agency, such as a police department, intelligence or security service, emergency response group, and the like, may operate a computer environment and issue agency-issued credentials to authorized users of that environment through the agency's identity server. Accordingly, an agency-issued credential may include multiple attributes that identify a user and the user's role within the agency.For example, a departmental credential may include an identifier for the department for which a user works, the user's rank, and qualifications, experience, and certifications (such as ICS (Incident Command System), FEMA (Federal Emergency Management Agency), IS (Independent Study), and the like). A departmental credential may also include a scope that encompasses the user's rights to specific computer-based services (such as data access rights, service access rights, and the like). Additionally, the departmental credential may include information that identifies User Device 130, such as the User Device 130 serial number.In some embodiments, the agency identity server can, for example, issue one credential associated with user device 130 and a separate credential associated with the user operating user device 130. In other embodiments, the agency identity server can issue one credential that authenticates both user device 130 and the user operating user device 130.

[0018] After User Device 130 receives the agency-issued credential from the agency identity server, User Device 130 can present the agency-issued credential to other devices to prove its identity and authorization. For example, if User Device 130 wants to access a computer-based service, User Device 130 sends the agency-issued credential to an application server hosting the service, and the application server uses the credential to verify the identity of User Device 130 or the user operating User Device 130 and to determine whether User Device 130 or the user is authorized to use the service and whether there are any restrictions on such use.In some implementations, this authorization occurs at a proxy, reverse proxy, firewall, API gateway, or PIP, which may be independent of or located within the application server. For example, an application server may host one or more services that can be accessed by user devices. Before user device 130 can access a service, however, an application server may authenticate user device 130 and / or the associated user using the credential issued by the agency. An application server may also use the agency-issued credential to determine which rights to grant to user device 130. For example, the services that the application server can access may have different levels of access (such as read-only, read and write, and so on).In some embodiments, an application server communicates with the agency identity server that issued the agency credential (or with other backend infrastructure that was initially accessed to issue the agency credential) to verify the identity of the user device or associated user and to obtain authorization and rights for the user device or associated user.

[0019] As also described above, in some embodiments a computer environment is used to handle an incident, such as a public safety incident. The network used can be referred to as an Incident Area Network (for example, Incident Area Network 140). An Incident Area Network can be used by user devices operated by users assigned to different departments. Furthermore, the Incident Area Network can be operated in a separate or offline mode, meaning that the Incident Area Network does not have remote access to other computer environments, such as the computer environments assigned to each department using the Incident Area Network.Therefore, the Incident Area Network may not have access to remote computing environments to access backend infrastructure, such as the agency identity server, to authenticate and authorize user devices and associated users accessing the Incident Area Network.

[0020] With renewed reference to Fig. 1. The incident identity server 110 can accordingly be configured to receive a department-issued credential from the user device 130, to authenticate the user device 130 using the department-issued credential (without using or accessing backend infrastructure such as the department incident server described above), and to issue an incident-issued credential for the Incident Area Network 140 by mapping attributes in the department-issued credential to attributes relevant to the incident to which the Incident Area Network 140 is assigned. Fig. Figure 3, for example, is a flowchart illustrating a procedure 400 performed by the Incident Identity Server 110 (the Electronic Processor 210) to issue an authorization credential for the Incident Area Network 140.

[0021] As this is in Fig. As shown in Figure 3, Procedure 400 involves receiving an agency-issued credential at Incident Identity Server 110 (at Block 410). For example, Incident Identity Server 110 can receive the agency-issued credential from User Device 130 via Incident Area Network 140. Specifically, User Device 130, as explained above, can receive and store an agency-issued credential, such as a digital X.509 certificate, from an agency identity server.The credential issued by the agency may include a distinguished name (DN) attribute, which contains identifying information about the entity to which the credential was issued (for example, User Device 130, one or more users operating the User Device, or both); an alternate name (ANN) attribute; a directory attribute; a certificate policy (CP) OID attribute; and the like. The credential issued by the agency may also include other attributes, such as an organization (represented by the attribute "O"), an organizational unit (represented by the attribute "OU"), a type, rank, experience, training, physical fitness, languages, and the like.

[0022] In some embodiments, the Incident Identity Server 110 optionally authenticates the user device 130 (or the user operating the user device) based on the agency-issued credential (not shown). For example, the Incident Identity Server 110 can identify an issuer of the agency-issued credential (such as an agency) and determine whether the issuer has been authorized to use the Incident Area Network 140 or services available on the Incident Area Network 140. In particular, the Incident Identity Server 110 can verify a signature on the agency-issued credential if the agency-issued credential is digitally signed.In some embodiments, the Incident Identity Server 110 can also evaluate other attributes contained in the agency-issued credential to authenticate whether the credential is original (not forged), valid (not expired), and represents an authorized agency or user.

[0023] As this is in Fig. As shown in Figure 3, the incident identity server 110 also retrieves an initial set of attributes from the agency-issued credential (at block 420). As described above, the agency-issued credential includes an initial set of attributes. This initial set of attributes can include attributes associated with the user of user device 130, user device 130, or both.In some embodiments, for example, the incident identity server 110 receives one agency-issued credential that includes attributes associated with the user of the user device 130, the user device 130, or both; and in other embodiments, the incident identity server 110 receives two agency-issued credentials, wherein a first agency-issued credential includes attributes associated with the user of the user device 130, and a second agency-issued credential includes attributes associated with the user device 130 (for example, a third set of attributes).The attributes assigned to user device 130 may include a user rank, a user skill level, a user qualification level, and a user training level, and the attributes assigned to user device 130 may include data processing capabilities (for example, encryption or other security capabilities) of user device 130, such as a user device type, a user device model number, an overall confidence level of user device 130, a confidence level for the nature of user device 130, a confidence level assigned to the capabilities of user device 130, and a user device security capability.

[0024] Incident Identity Server 110 maps the first set of attributes to a second set of attributes (at block 430). For example, Incident Identity Server 110 (in memory 220) can store multiple mapping rules. These mapping rules can define which departments can access Incident Area Network 140 and which attributes should be included in an incident credential issued by Incident Identity Server 110. Examples of mapping rules (in pseudo-code format) are given below. If ORGANIZATION = "CPD" and RANK = "Lieutenant", then assign ROLE = "Lieutenant" If ORGANIZATION = "NYPD" and RANK = "Detective", then assign ROLE = "Lieutenant" If ORGANIZATION = "County Sheriff" and RANK = "Deputy Sheriff", then assign ROLE = "Lieutenant" If QUALIFICATIONS include ICS-400, then assign to ICS_ROLE_ELIGIBLE = "Incident Commander" If QUALIFICATIONS include ICS-200, then assign to ICS_ROLE_ELIGIBLE = “Section Chief” If QUALIFICATIONS include HAZMAT, then assign to ICS_ROLE_ELIGIBLE = "Hazmat Technician" If QUALIFICATIONS include HAZMAT and FEMA-IS-700, then assign to ICS_ROLLE_ELIGIBLE = “HAZMAT SAFETY OFFICER”

[0025] As mentioned above, the credential issued by an agency can include attributes associated with user device 130, the user operating user device 130, or both. Therefore, in some embodiments, the incident identity server 110 can use attributes associated with user device 130, the user using user device 130, or both to determine the second set of attributes. For example, the mapping rules applied by the incident identity server 110 can use attributes associated with the user using user device 130, the user device 130 itself, or both to determine the second set of attributes.If the credential issued by a department and received by Incident Identity Server 110 does not include certain attributes accessed by the mapping rules, Incident Identity Server 110 may also request that User Device 130 provide this information. For example, if the credential issued by a department and received by Incident Identity Server 110 is associated with the user of User Device 130 but not with the device itself, Incident Identity Server 110 may request data that identifies User Device 130 (either as a request for a separate credential for User Device 130 or as a request for data that identifies User Device 130 and is not included in the credential).Accordingly, the incident identity server 110 can determine the second set of attributes based on attributes obtained from a plurality of credentials (for example, a first credential associated with a user operating user device 130, and a second credential associated with user device 130).

[0026] In some embodiments, the incident identity server 110 uses data that identifies the user device 130, such as a separate credential (for example, a second credential issued by a department) associated with the user device 130, to determine whether the user device 130 is a department-issued or department-approved device. For example, if the user device 130 is not a department-issued or department-approved device, it may lack certain functionalities and capabilities, such as encryption capabilities, that may be required to grant a user with specific privileges to the user device 130.

[0027] In some implementations, the Incident Identity Server 110 also uses mapping rules to define a scope. As mentioned above, the scope can define the rights of a specific user or user device. Accordingly, the mapping rules can map attributes from a credential issued by a department to a credential scope associated with the Incident Area Network 140. Examples of mapping rules for defining the scope of a new credential are given below (in pseudo-code format). If attribute “Incident Command”, then assign scope to “ComandCentral(ALL)” If attribute “Hazmat-*”, then assign scope to “CommandCentral(Hazmat)”

[0028] In the example mapping rules above, the presence of any attribute with a value of "Incident Command" or "Hazmat" defines a specific scope for the credential. Accordingly, in some implementations, the mapping rules do not only search within the scope of the received, agency-issued credential to define the scope for the new credential. Rather, the mapping rules consider other (non-scope-related) attributes contained in the agency-issued certificate to define the scope for the new credential. In some implementations, Incident Identity Server 110 may also use the values ​​from this second set of attributes to define the scope.

[0029] The assignment rules can differ based on the type of incident assigned to Incident Area Network 140 (for example, different rules for a high-rise fire than for a chemical accident in a residential area). In some implementations, the rules can also change dynamically based on the incident context. For example, the assignment rules can change based on the type of incident, the size of the incident, a condition of the incident, the location of the incident, the time of day, the number of resources involved, the type of resources involved, or any required but missing resources. In particular, the assignment rules can assign more users to hazardous materials roles during a chemical accident than during a fire.If a chemical accident spreads, the assignment rules can still assign more users to dangerous goods roles and grant those users more access rights than if the chemical accident were more limited.

[0030] Alternatively or additionally to using mapping rules, the Incident Identity Server 110 can apply a mapping table or function to generate the second set of attributes. For example, illustrates Fig. 4. An example mapping table 450 (in human-readable format) that the incident identity server 110 can use to map the first set of attributes to the second set of attributes. How this is done in Fig. As shown in Figure 4, in some embodiments different values ​​can be defined for the second set of attributes based on the context of the incident. For example, if the context of the incident requires a high level of security or management, the second set of attributes can be defined as shown in the "High" column. If the context of the incident requires a medium level of security or management, the second set of attributes can be defined similarly to the "Medium" column, and if the context of the incident requires a basic level of security or management, the second set of attributes can be defined as shown in the "Basic" column. As shown in Fig. As shown in Figure 4, the second set of attributes in some embodiments includes one or more ICS attributes (ICS = incident command system / incident coordination system) (for example, an ICS role). The second set of attributes can also identify the incident, for example, by specifying an incident type, an incident location, and other static or dynamic identification data.

[0031] With renewed reference to Fig. 3. The incident identity server 110 generates an incident-issued credential for the Incident Area Network 140 (at block 440). The incident-issued credential may include the second set of attributes. Additionally or alternatively, the incident-issued credential may include the scope allocated based on the first set of attributes. In some embodiments, the incident identity server 110 may digitally sign the incident-issued credential by signing it with a private key of the incident identity server 110. After generating the incident-issued credential, the incident identity server 110 issues the incident-issued credential to the user device 130.Subsequently, the user device 130 uses the credential issued for the incident to access computerized services available through the Incident Area Network 140.

[0032] Fig. Figure 5, for example, is an operational flowchart illustrating communication between user device 130, incident identity server 110, and incident application server 120. User device 130 sends the agency-issued credential to incident identity server 110. As described above, incident identity server 110 maps the first set of attributes contained in the agency-issued credential to the second set of attributes and the scope. Specifically, as described above, incident identity server 110 applies one or more mapping rules, tables, or functions to map the first set of attributes (for example, X.509 attributes) to the second set of attributes (for example, ICS attributes) and the scope.The incident identity server 110 generates the credential issued for the incident based on the second set of attributes and the scope, and sends the credential issued for the incident to the user device 130. The user device 130 can then send the credential issued for the incident to the incident application server 120 as part of a request to access computer-based services hosted by the incident application server 120. As mentioned above, in some embodiments, the incident application server 120 can communicate with the incident identity server 110 to verify data contained in a received credential issued for the incident.

[0033] As this is in Fig. As shown in Figure 6, the incident identity server 110 can optionally communicate with an attribute provider 500 (for example, a server, a database, or a combination thereof). As shown in Figure 6, the incident identity server 110 can optionally communicate with an attribute provider 500 (for example, a server, a database, or a combination thereof). Fig. As shown in Figure 6, the incident identity server 110 can communicate with the attribute provider 500 through the Incident Area Network 140. In some embodiments, the attribute provider 500 is also included in the incident identity server 110. In other embodiments, the incident identity server 110 can communicate with multiple attribute providers.

[0034] Attribute provider 500 tracks which user devices and associated users are using or authorized to use Incident Area Network 140. Accordingly, the incident identity server 110 can update attribute provider 500 with the credential issued for the incident, which was generated for Incident Area Network 140, or with attributes or scope contained therein. In some embodiments, the incident identity server 110 updates attribute provider 500 using the SCIM protocol (SCIM = system for cross-domain identity management), an API, or another mechanism. In some embodiments, the incident identity server 110 assigns a user's associated attributes to attribute provider 500.

[0035] In some embodiments, the incident application server 120 can communicate with the attribute provider 500 to verify an authorization credential issued for the incident and received from the user device 130. Alternatively or additionally, the incident application server 120 can access data managed by the attribute provider 500 to determine authorized users present at the incident associated with the Incident Area Network 140 and their respective attributes (roles and rights), which can be used to manage role assignment and other services. For example, the incident application server 120 can host an incident management service for managing the users of the Incident Area Network 140. Furthermore, in some embodiments, the data managed by the attribute provider 500, or a portion thereof, can be stored locally on the incident application server 120.

[0036] Furthermore, in some embodiments, the incident identity server 110 uses the attribute provider 500 to issue credentials issued initially for the incident, such as long-term access tokens (sometimes referred to as refresh tokens), which allow the user device 130 to obtain successively updated or incident-specific credentials. Fig. Figure 7, for example, is an operational flowchart illustrating communication between the user device 130, the incident identity server 110, the attribute provider 500, and the incident application server 120. As shown in Fig.As shown in Figure 7, user device 130 sends the agency-issued credential to incident identity server 110. Incident identity server 110 maps the first set of attributes contained in the agency-issued credential to the second set of attributes, as described above. Incident identity server 110 uses the second set of attributes to generate a long-term credential issued for the incident, such as a refresh token, which incident identity server 110 sends to user device 130. Incident identity server 110 continues to store the second set of attributes at attribute provider 500.

[0037] After user device 130 receives the long-term credential issued for the incident, it sends a request to incident identity server 110 to access one or more computer-based services provided by incident application server 120. The request may include the long-term credential issued for the incident, as well as data identifying which services user device 130 wishes to access. Upon receiving the request, incident identity server 110 queries attribute provider 500 for the pre-defined second set of attributes associated with user device 130 and generates a short-term credential issued for the incident, such as an identity certificate.In some embodiments, the short-term credential issued for the incident is similar to the incident-issued credential described above, comprising a scope and a plurality of attributes, such as ICS attributes. The scope contained in the incident-issued short-term credential can specify the rights of the user device 130 (and the user operating the user device) to access requested services. The incident identity server 110 can determine the scope based on the second set of attributes stored in the attribute provider 500 as part of the generation of the incident-issued short-term credential.Alternatively or additionally, the incident identity server 110 can determine the scope as part of generating the long-term credential issued for the incident, and it can store the scope with the second set of attributes in the attribute provider 500.

[0038] The incident identity server 110 sends the short-term credential issued for the incident to the user device 130, which the user device 130 can then send to the incident application server 120 as part of a request to access computer-based services hosted by the incident application server 120. As mentioned above, in some embodiments, the incident application server 120 can communicate with the incident identity server 110, the attribute provider 500, or both to verify data contained in a received short-term credential issued for the incident.

[0039] As mentioned above, in some embodiments the functionality provided by the Incident Identity Server 110 can be distributed among multiple devices or electronic processors. For example, in some embodiments the mapping performed by the Incident Identity Server 110, as described above, can be performed by an event listener / attribute mapping service provided by the identity server or a separate server. In some embodiments, for example, the user device 130 can request authentication from the Incident Identity Server 110 by providing a credential issued by an agency, as described above.The incident identity server 110 can be configured to perform initial authentication of the user device 130, as described above, based on data contained in the credential issued by the agency. Once the user device 130 is authenticated, the incident identity server 110 can generate an initial incident-issued credential, such as an access token that includes one or more of the attributes contained in the agency-issued credential. The initial incident-issued credential can also include a scope that grants access to the event listener / attribute mapping service.The incident identity server 110 returns the initial incident credential to the user device 130, and the user device 130 sends the initial incident credential to the event listener / attribute mapping service, which performs the mapping as described above and issues a subsequent incident credential, such as a long-term incident credential, as described above. In this embodiment, the incident identity server 110 can thus perform authentication to control which devices access the event listener / attribute mapping service. In some embodiments, the event listener / attribute mapping service also stores the mapped attributes (the second set of attributes) and, optionally, the scope, at the attribute provider 500.Therefore, the incident identity server 110 can respond directly to credential requests from the user device 130 by accessing the attributes and, optionally, the scope stored in the attribute provider 500. Alternatively or additionally, the user device 130 can request an initial credential issued for the incident from the attribute provider 500.

[0040] Specific embodiments have been described in the preceding specification. However, it is clear to those skilled in the art that various modifications and changes can be made without departing from the spirit of the invention, as set out in the claims below. Accordingly, the specification and the figures are to be understood in an illustrative rather than a restrictive sense, and all such modifications are intended to be in keeping with the spirit of the present teachings.

[0041] The benefits, advantages, problem solutions, and any conceivable element that leads to or enhances any benefit, advantage, or solution shall not be construed as critical, necessary, or essential features or elements of any claim or all claims. The invention is defined exclusively by the attached claims, including any amendment made during the pendency of the present application and all equivalents of such claims as published.

[0042] Furthermore, in this document, relational expressions such as first and second, above and below, and the like are to be used solely to distinguish one entity or action from another, without necessarily requiring or implying any actual relationship or order between such entities or actions. The expressions "includes," "comprising," "has," "having," "include," "containing," "containing," or any variation thereof are to cover non-exclusive inclusion, so that a process, procedure, article, or device that includes, has, includes, or contains a list of elements may not only include such elements but may also include other elements not expressly listed or inherent in such processes, procedures, articles, or devices. An element that continues with "includes... a," "has..."The terms "one," "includes... one," and "contains... one" do not, without further stipulations, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprise, have, include, or contain the element. The terms "one" and "a" are defined as one or more unless explicitly stated otherwise herein. The terms "essentially," "essentially," "approximately," "about," or any other version thereof are defined as "being close to" as is clear to those skilled in the art, and in one non-limiting embodiment, the term is defined as being within 10%, in another embodiment within 5%, in another embodiment within 1%, and in yet another embodiment within 0.5%. The term "coupled," as used herein, is defined as "connected," although not necessarily directly and not necessarily mechanically.A device or structure that is “configured” in a certain way is configured at least in that way, but may also be configured in at least one other way not listed.

[0043] It is desired that some embodiments include one or more generic or specialized processors (or “processing devices”), such as microprocessors, digital signal processors, custom processors, and freely programmable field-gate arrays (FPGAs), and unique stored program instructions (comprising both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuitry, some, most, or all of the functions of the method and / or device described herein.Alternatively, some or all functions can be implemented by a state machine that has no stored program instructions, or in one or more application-specific integrated circuits (ASICs) where each function, or some combinations of certain functions, are implemented as custom logic. Naturally, a combination of the two approaches can be used.

[0044] Furthermore, an embodiment can be implemented as a computer-readable storage medium containing computer-readable code stored thereon for programming a computer (which, for example, includes a processor) to perform a method described and claimed herein. Examples of such computer-readable storage media include, but are not limited to: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (read-only memory), a PROM (programmable read memory), an EPROM (erasable programmable read memory), an EEPROM (electrically erasable programmable read memory), and flash memory.Furthermore, it can be expected that a person skilled in the art, regardless of possible considerable effort and a large selection of designs, which is justified, for example, by available time, current technology and economic considerations, guided by the concepts and principles disclosed herein, will be able to produce such software instructions, programs and ICs with minimal experimental effort.

[0045] The summary of the disclosure is provided to allow the reader to quickly grasp the nature of the technical disclosure. It is submitted with the understanding that it is not intended to interpret or limit the spirit or meaning of the claims. Furthermore, it is clear from the preceding detailed description that various features in different embodiments are grouped together to streamline the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly stated in each claim. Rather, as is evident from the following claims, an inventive subject matter is present in fewer than all the features of any single disclosed embodiment.Thus, the following claims are integrated into the detailed description, with each claim standing alone as a separately claimed subject matter.

Images