Dual Authentication Service Architecture for Container Security

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing authentication service schemes lack flexibility and efficiency, particularly in managing different authentication processes within a container and failing to distinguish between sensitive and insensitive areas, leading to unnecessary authentication efforts.

Innovation Solution

Implementing a dual authentication service architecture with both container-wide and application-specific services, along with policy rules to ensure mutual respect between services, and using distributed login contexts and enhanced callback handlers to manage authentication and authorization efficiently.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Stability of the object's composition

If a single container-wide authentication service is used for all applications, then authentication consistency is improved, but application-specific authentication requirements cannot be met

Engineering Contradiction:
Improveauthentication consistencyVSAvoidapplication-specific authentication capability
Core Design Contradiction:
Stability of the object's compositionVSAdaptability or versatility

Solution Approach 1:

The authentication service is segmented into two independent parts: a container-wide authentication service that provides consistent authentication across all applications, and application-specific authentication services that can be implemented by individual applications. Each part can operate independently and serve different purposes, resolving the contradiction between consistency and adaptability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The container-wide authentication service serves as a universal authentication mechanism that can be used by any application within the container. Applications can choose to use this universal service or implement their own specialized service, making the system multi-functional and adaptable to different authentication needs while maintaining overall consistency.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If authentication is applied to all areas within a container, then security coverage is improved, but unnecessary authentication overhead is introduced for insensitive areas

Engineering Contradiction:
Improvesecurity coverageVSAvoidauthentication overhead
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Different quality levels of authentication are applied to different areas: sensitive areas require full authentication verification, while insensitive areas can use simplified or no authentication. This local differentiation allows the system to maintain security coverage where needed while reducing unnecessary overhead in other areas.

Inventive Principle:
Principle #3Local quality

3Adaptability or versatility

If multiple authentication services coexist in a container, then authentication flexibility is improved, but service coordination complexity increases

Engineering Contradiction:
Improveauthentication flexibilityVSAvoidservice coordination complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

An authentication selector acts as an intermediary component that mediates between applications and authentication services. It receives authentication requests from applications, determines which authentication service should be used (container-wide or application-specific), and coordinates the authentication process accordingly. This mediator simplifies the complexity of coordinating multiple services.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS7584355B1Authentication service schemes
Publication Date: 2009.09.01 SAP SE
  • US7584355B1 patent drawing
  • US7584355B1 patent drawing
  • US7584355B1 patent drawing

AI summary

Improved authentication service schemes are described. A first technique enables application specific authentication services even if container-wide authentication services are made available. A second technique prevents an authentication service from being performed if an attempt is made to reach an item of insensitivity within a protected area. A third technique introduces “get/set” functions into a login module callback handler arrangement for retrieving/imposing information from/to a communication session with a user that the login module is authenticating. A fourth technique distributes a login context function so that a network resides between separate portions of the login context function. A fifth technique uses a fallback handler in an application based authentication service so that a container-wide authentication service can be used.