Abstract: Techniques are disclosed for network policy verification system that can obtain a set of connectivity paths of a containerized environment that individually indicate connections between pairs of containers. Identify a first container and a second container of a pair based at least in part on a connectivity path. Determine a network policy corresponding to the connectivity path that indicates an expected result of that particular connection. A connection can be initiated between the two containers. The result may be presented at a user device based at least in part on identifying that the result is different from the expected result indicated by the network policy corresponding to the connectivity path.

Abstract: A computer system may receive one or more requests for access to one or more cloud services and may store the one or more requests in a request log. The computer system may receive one or more access rules applicable to cloud service access rights. The computer system may aggregate the one or more requests of the request log to determine access requirements for a container, the container being configured to store one or more applications. The computer system may generate and store container access policies that define access of a container and the one or more cloud services, the container access policies based at least in part on the aggregated one or more requests and the one or more access rules. The computer system may send the container access policies to a request forwarder of a compute instance in a production environment.

Abstract: Techniques are disclosed for query processing system that can, when queried, generate a result related to one or more connectivity paths and/or one or more network security rules. Network security rules and connectivity paths may be stored in corresponding data structures (e.g., sets of attributes) that may be utilized with a number of set operations. The user may issue a query requesting the system to apply a rule to a path, a set of rules to a set of paths, to identify if one set of rule(s) are equivalent to another set of rule(s), and the like. Utilizing this query processing system can enable a user to identify effects of one or more network rules with respect to traffic being allowed or restricted along particular connectivity paths between components of the system.

Abstract: A system and technique for a Request Forwarder as for a computer network architecture is disclosed to provide selective access to one or more cloud services. In some implementations, a computer system may receive a request for access to a cloud service, the request including a container credential. The computer system may determine an identification of the container using the container credential. The computer system may verify that the container requesting access to the cloud service is authorized based at least in part on stored policies. Based at least in part on the determination that the container requesting access to the cloud service is authorized: receiving instance credential from a metadata service. The computer system may include the instance credential with the request. The computer system may send the request to the cloud service. In various examples, the Request Forwarder can be provided as a service.

Abstract: Techniques are disclosed for generating network security policies for different versions of a component of an application deployed in a computing environment where the different versions have potentially different network requirements and the different versions operate together at the same time in the computing environment. The disclosed techniques include capabilities for enabling different versions of a component of a containerized application to co-exist at the same time on different computing nodes in a cluster of nodes in a containerized environment that deploys and executes the application. The techniques additionally include capabilities for enabling different network policies to be generated for the different versions of the component, where each component has potentially different network requirements. The techniques provide a mechanism to create precise, per-component network policies, while respecting the overall coarse-grained policies of the containerized application.

Abstract: Techniques are disclosed for automatically inferring software-defined network policies from the observed workload in a computing environment. The disclosed techniques include monitoring network traffic flow originating from network interfaces corresponding to containers that execute components of an application, recording details of a new network connection or a change in the existing network connection, obtaining information concerning the components of the application, identifying metadata for a component involved in the new network connection or the change in an existing network connection based on a comparison of the details of the new network connection or a change in the existing network connection and the information concerning the components of the application, generating a network policy for the component using at least the metadata for the component, and integrating the network policy for the component into a deployment package for the application.

Abstract: Techniques are disclosed for query processing system that can, when queried, generate a result related to one or more connectivity paths and/or one or more network security rules. Network security rules and connectivity paths may be stored in corresponding data structures (e.g., sets of attributes) that may be utilized with a number of set operations. The user may issue a query requesting the system to apply a rule to a path, a set of rules to a set of paths, to identify if one set of rule(s) are equivalent to another set of rule(s), and the like. Utilizing this query processing system can enable a user to identify effects of one or more network rules with respect to traffic being allowed or restricted along particular connectivity paths between components of the system.

Abstract: An authentication channel is established between a mobile device and a transaction terminal that uses a keypad for access control. The terminal keypad is assumed to be untrusted, whereas the mobile device has a trusted interface that only the device user can access and use. The transaction terminal includes a short-range communication device, and a keypad interface application configured to communicate with an external keypad device in lieu of the transaction terminal's own keypad. The mobile device includes a mobile app. In response to detecting a user access request, a handshake protocol is performed between the keypad interface application in the transaction terminal and the keypad interface function in the mobile device. If the handshake protocol succeeds, the user is notified that the transaction terminal is trusted. The user then enters his or her password and/or PIN on the mobile device in lieu of direct entry via the terminal keypad.

Abstract: A rich client performs single sign-on (SSO) to access a web- or cloud-based application. According to the described SSO approach, the rich client delegates to its native application server the task of obtaining a credential, such as a SAML assertion. The native server, acting on behalf of the user, obtains an assertion from a federated identity provider (IdP) that is then returned to the rich client. The rich client provides the assertion to a cloud-based proxy, which presents the assertion to an identity manager to attempt to prove that the user is entitled to access the web- or cloud-based application using the rich client. If the assertion can be verified, it is exchanged with a signed token, such as a token designed to protect against cross-site request forgery (CSRF). The rich client then accesses the web- or cloud-based application making a REST call that includes the signed token. The application, which recognizes the request as trustworthy, responds to the call with the requested data.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: In a cloud computing environment, a user authenticates to multiple cloud services concurrently. A master service has knowledge of or tracks the cloud service(s) to which a user is authenticated. Each cloud service may enforce its own inactivity period, and the inactivity period of at least first and second cloud services may be distinct from one another. When the master service receives an indication that the authenticated user is attempting to take an action at a first cloud service despite an activity timeout there, the master service issues a status request to at least the second cloud service to determine whether the user is still active at the second cloud service (despite its different inactivity period). If the user is still active at the second cloud service, the master service provides a response, selectively overriding (re-setting) the activity timeout at the first cloud service to permit the action.

Abstract: An authentication channel is established between a mobile device and a transaction terminal that uses a keypad for access control. The terminal keypad is assumed to be untrusted, whereas the mobile device has a trusted interface that only the device user can access and use. The transaction terminal includes a short-range communication device, and a keypad interface application configured to communicate with an external keypad device in lieu of the transaction terminal's own keypad. The mobile device includes a mobile app. In response to detecting a user access request, a handshake protocol is performed between the keypad interface application in the transaction terminal and the keypad interface function in the mobile device. If the handshake protocol succeeds, the user is notified that the transaction terminal is trusted. The user then enters his or her password and/or PIN on the mobile device in lieu of direct entry via the terminal keypad.

Abstract: An authentication channel is established between a mobile device and a transaction terminal that uses a keypad for access control. The terminal keypad is assumed to be untrusted, whereas the mobile device has a trusted interface that only the device user can access and use. The transaction terminal includes a short-range communication device, and a keypad interface application configured to communicate with an external keypad device in lieu of the transaction terminal's own keypad. The mobile device includes a mobile app. In response to detecting a user access request, a handshake protocol is performed between the keypad interface application in the transaction terminal and the keypad interface function in the mobile device. If the handshake protocol succeeds, the user is notified that the transaction terminal is trusted. The user then enters his or her password and/or PIN on the mobile device in lieu of direct entry via the terminal keypad.

Abstract: An authentication channel is established between a mobile device and a transaction terminal that uses a keypad for access control. The terminal keypad is assumed to be untrusted, whereas the mobile device has a trusted interface that only the device user can access and use. The transaction terminal includes a short-range communication device, and a keypad interface application configured to communicate with an external keypad device in lieu of the transaction terminal's own keypad. The mobile device includes a mobile app. In response to detecting a user access request, a handshake protocol is performed between the keypad interface application in the transaction terminal and the keypad interface function in the mobile device. If the handshake protocol succeeds, the user is notified that the transaction terminal is trusted. The user then enters his or her password and/or PIN on the mobile device in lieu of direct entry via the terminal keypad.

Abstract: An authentication channel is established between a mobile device and a transaction terminal that uses a keypad for access control. The terminal keypad is assumed to be untrusted, whereas the mobile device has a trusted interface that only the device user can access and use. The transaction terminal includes a short-range communication device, and a keypad interface application configured to communicate with an external keypad device in lieu of the transaction terminal's own keypad. The mobile device includes a mobile app. In response to detecting a user access request, a handshake protocol is performed between the keypad interface application in the transaction terminal and the keypad interface function in the mobile device. If the handshake protocol succeeds, the user is notified that the transaction terminal is trusted. The user then enters his or her password and/or PIN on the mobile device in lieu of direct entry via the terminal keypad.

Abstract: An authentication channel is established between a mobile device and a transaction terminal that uses a keypad for access control. The terminal keypad is assumed to be untrusted, whereas the mobile device has a trusted interface that only the device user can access and use. The transaction terminal includes a short-range communication device, and a keypad interface application configured to communicate with an external keypad device in lieu of the transaction terminal's own keypad. The mobile device includes a mobile app. In response to detecting a user access request, a handshake protocol is performed between the keypad interface application in the transaction terminal and the keypad interface function in the mobile device. If the handshake protocol succeeds, the user is notified that the transaction terminal is trusted. The user then enters his or her password and/or PIN on the mobile device in lieu of direct entry via the terminal keypad.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: A password protection application is executed on a mobile device and provides an interface by which an authorized user can define and configure a “data protection profile” for the device. This profile defines at least one security event (criteria or condition) associated with the device, and at least one protection action that should occur to protect data on the device upon the triggering of the event. Once defined in a profile, the application monitors for the occurrence of the security event. Upon the occurrence of the specified event, the protection action is enforced on the device to protect the data.

Abstract: An un-authenticated user attempts to access a protected resource at a Web- or cloud-based application from within a rich client. The client has an associated local HTTP server. Upon being refused access, a browser-based login dialog is opened automatically within an embedded browser panel. After receipt of the user's login credential in the panel, the browser passes the credential server application. If the user is authenticated, the browser-based dialog receives a cookie establishing that the user is authenticated for a session. The browser then automatically makes a request to the HTTP server, passing the cookie. Upon receipt of the request at the rich client HTTP server, the rich client saves the cookie in an associated data store, shuts down the login dialog, and re-issues the original request to the server, this time passing the cookie. The rich client, having provided the cookie, is then permitted to access the resource.