Security Contracts a Property-Based Approach to Support Security
Patterns
Sylvain Gu
´
erin
1
, Joel Champeau
1
, Salvador Mart
´
ınez
2
and Raul Mazo
1
1
Lab-STICC, ENSTA Bretagne, Brest, France
2
Lab-STICC, IMT Atlantique, Brest, France
Keywords:
Design by Contract, Security Patterns, Security Contracts, Runtime Monitoring.
Abstract:
Security patterns represent reusable solutions and best practices intended to avoid security-related flaws in
software and system designs. Unfortunately, the implementation and enforcement of these patterns remains a
complex and error-prone task. As a consequence, and besides implementing a given security pattern, appli-
cations often remain insecure w.r.t. the security risk they intended to tackle. This is so for two main reasons:
1) patterns are rarely re-usable without adaptation, and thus concrete implementations may fail to deal with
a number of (often implicit) properties, which must hold in order for the pattern to be effective; 2) patterns
are deployed in environments with uncertainties that can only be known at runtime. In order to deal with this
problem, we propose here Security Contracts, a framework that permits the specification and runtime monitor-
ing of security patterns and related properties (including temporal ones) in both new and existing applications.
It is based on an extension of the Design-by-Contract paradigm to enable the specification of security patterns
and the runtime adaptation of applications. We demonstrate the feasibility of our approach with an implemen-
tation and its evaluation on a framework used worldwide in web technologies, Spring.
1 INTRODUCTION
Information systems are core components of nowa-
days institutions and companies and often subject to a
wide range of security threats. These threats may af-
fect both, the information they manage and their cor-
rect functioning. To cope with these security threats,
research and industry efforts have led to the iden-
tification of a number of generic solutions to miti-
gate various security vulnerabilities. Among them,
we may find: authentication, permission handling, re-
source access, etc. These solutions, which are meant
to capture security expertise and provide architec-
tural and functional guidelines to system developers,
are known as security design patterns (Fernandez-
Buglioni, 2013; Yoshioka et al., 2008).
As reusable as they may be, patterns need to be of-
ten adapted to the problem and solution domains, and
thus implementations may deviate from the initial pat-
tern description. Secondly, patterns may depend on
environment uncertainties that can only be known at
run-time, imposing a monitoring requirement for safe
enforcement. Consequently, a number of (often im-
plicit) properties among those that must hold in order
for a pattern to be effective may be left unsatisfied (by
missing a correct implementation, run-time enforce-
ment, or both). In this sense, the need for an approach
to help with both the specification of security patterns
and their monitoring at run-time appears to be criti-
cal. Such an approach must provide the means to: 1)
Specify complex patterns with a focus on guaranteed
security properties; 2) Instantiate and monitor them
on both new (in development) and existing applica-
tions. Existing applications must be enhanced in case
of faulty or incomplete security patterns.
We propose a solution based on an extension
of the Design-by-Contract (DbC) paradigm (Meyer,
1992), a method designed to formalize the interac-
tion between components in terms of expectations and
guarantees. In this sense, our solution supports the
definition of security patterns as security contracts
and their monitoring and enforcement through run-
time adaptation. We call this run-time phase Execu-
tion under Contract (EuC).
We take advantage of Pamela (Gu
´
erin et al.,
2021), a model-oriented programming framework for
Java. At design time, we use Pamela to describe
reuseable security patterns. The description focuses
on the security properties that the contract is assuming
to guarantee. Then, we use annotations in the applica-
Guérin, S., Champeau, J., Martínez, S. and Mazo, R.
Security Contracts a Property-Based Approach to Support Security Patterns.
DOI: 10.5220/0012305600003648
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 10th International Conference on Information Systems Security and Privacy (ICISSP 2024), pages 103-111
ISBN: 978-989-758-683-5; ISSN: 2184-4356
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.
103

tion Java code, in order to instantiate the pattern. At
runtime, the Pamela engine intercepts the execution
of the application, allowing security property moni-
toring and enforcement.
We validate our approach by applying an authenti-
cator security pattern on a widely used Spring frame-
work (Johnson et al., 2004).
The remainder of the paper is organized as fol-
lows. Section 2 presents some preliminaries on Se-
curity Design Patterns and Design-by-Contract. The
security contracts approach is described in Section 3
followed by the presentation of our case study in Sec-
tion 4 together with a critical discussion. Section 5
deals with related work. We end the paper in Sec-
tion 6 by presenting conclusions and future work.
2 PRELIMINARIES & EXAMPLE
This section starts with a brief presentation of the se-
curity design pattern concept. After that, we describe
the Authenticator security pattern which will serve as
a running example throughout the rest of the paper.
2.1 Security Design Patterns
In order to face threats in terms of software se-
curity, security design patterns have naturally im-
posed themselves in the continuity of design pat-
terns. An abundant literature has been published,
including books containing patterns catalogs (Schu-
macher et al., 2013). Based on these catalogs, differ-
ent works have been developed to, for example, pro-
vide pattern languages to classify and create relations
between patterns according to threats (Fernandez-
Buglioni, 2013), formalize patterns (Behrens, 2018)
or study them in specialized domains such as auto-
mobiles (Cheng et al., 2019).
Like in (Fernandez et al., 2018), a security pattern
is made up of several parts. where mainly the prob-
lem, the solution and some additional comments are
defined. We illustrate these parts in the next section
with the Authenticator pattern
2.2 The Authenticator Pattern
The Authenticator pattern is characterized as follows:
• The Intent. How to verify that a subject (user or
system) intending to access the system is who she
claims to be? The subject must present informa-
tion that is recognized by the system and receives
some proof of successful authentication.
• The context. Computer systems contain sensible
resources. We only want subjects that have some
reason to be in our system to enter the system.
• The problem. The purpose is to prevent a mali-
cious subject from trying to impersonate a legiti-
mate user in order to have access to sensible re-
sources. This could be particularly critical when
the impersonated user has a high level of privi-
leges or offers the possibility to escala this level.
• The forces. We emphasize some forces on this
pattern:
– Authentication information protection. The
pattern must assume the non-usurpation of the
authentication information.
– Authenticate authority integrity is preserve dur-
ing its life to enforce the non-modification of
the authentication information.
– Proof of identity tamper resistance. The in-
tegrity of the proof of identity presented by the
user is preserved during its life cycle.
– Authentication frequency. User requests to au-
thenticate are limited in a given period of time.
The objective is to prevent brute-forced auto-
matic attempts.
This strength list represents properties that must
be respected to ensure a proper use of the pattern.
• The solution. The definition of the solution in-
cludes a structural part and a behavioral part. The
structural part is generally expressed with UML
class diagrams such as in Figure 1, which defines
several entities:
– A Subject needing to be authenticated,
– A Proof of Identity, token given to the subject
once authentication is complete,
– An Authenticator is the object which imple-
ments an authentication algorithm and creates
the Proof of Identity,
– Authentication Information are the information
provided by Subject to the Authenticator.
The behavioral part is based on several interaction
scenarios between the structural entities. These
scenarios are illustrated through the code of our
implementation as described in Section 4.
Based on this pattern, we will demonstrate how to
create a security contract with related properties and
how we ensure that the properties are guaranted dur-
ing the execution.
With our approach, we create a continuum be-
tween the development process with the Design by
Contract (DbC) and the Execution under Contract
(EuC), to verify at runtime the specified security prop-
erties.
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
104

<< creates >>
Authentication Information
Subject Authenticator
ProofOfIdentity
request
checks
*
*
1
1
1
Figure 1: UML class diagram of the Authenticator pattern.
3 SECURITY CONTRACTS
APPROACH
We devote this section to the description of our Secu-
rity Contracts approach, which builds on our prelim-
inary work in (Silva et al., 2020). Security Contracts
is an extension of the DbC method and the monitor-
ing of these security contracts. Concretely, we extend
DbC that the contracting party is composed not only
of individual classes and methods, but sets of col-
laborating classes as we may find in securitypatterns.
For the runtime support, our extension includes tool-
ing to instantiate security contracts as cross-cutting
aspects on host applications, and runtime monitoring
(and enforcement) of pattern properties (i.e., EuC). A
library of security contracts is established to improve
the reusability of these security contracts, notably for
existing applications. In particular, this section (i)
formally describes security contracts, (ii) presents the
application of such contracts to a security pattern, and
(iii) presents tooling support the monitoring of the
authenticator pattern properties, to illustrate our ap-
proach.
3.1 Contract Specification
Let us exemplify the definition of a security contract
for the Authenticator pattern. To do so, we will first
use formal Boolean expressions in order to describe
the contract properties. Note that these Boolean ex-
pressions suppose the existence of classes represent-
ing the concepts of the authenticator pattern such as
Subject. The Authenticator pattern intrinsically de-
fines five security properties (four implicit properties
and two functional properties), which have been pre-
viously introduced as pattern forces in Section 2:
1. Unicity of the Couple Subject/Authentication
Information.
P1 : ∀a, b ∈ I
Sub ject
,
a ̸= b =⇒ a.authIn f o ̸= b.authIn f o
2. Authentication Information Integrity.
P2 : ∀a ∈ I
Sub ject
, a.authIn f o = a.authIn f o
ini
3. Authenticate Authority Integrity.
P3 : ∀a ∈ I
Sub ject
, a.authenticator = a.authenticator
ini
4. Verification of the Validity or an Undefined Proof of
Identity.
P4 : ∀a ∈ I
Sub ject
, (a.idProo f =
/
0)∨
(a.idProo f = a.authenticator.request(a.authIn f o))
5. Continue verification of the proof of identity.
P5 : sel f .idProo f =
sel f .authenticator.request(sel f .authIn f o)
Remark.After authentication, the proof of identity
must always match the value initially returned by the
query method. Joint verification of properties P4 and
P5 guarantees the validity of the identity proof through-
out the session.
The specification of the authenticator security
contract is now defined with these properties and the
abstract definition of the entities of the Authenticator
pattern in Figure 1. Note that this security contract
is naturally extensible by adding security properties
in increments throughout the life cycle of the applica-
tion. In Section 4, we illustrate the extension capacity
of our security contracts.
3.2 Deployment, Monitoring and
Enforcement
For the operationalization of our Security Contracts
we describe the PAMELA framework where proper-
ties are annotations and the properties are ensured at
runtime by the framework.
3.2.1 The Authenticator Security Contract in
PAMELA
To illustrate the main features of our implementation,
we present here how the Authenticator contract is im-
plemented with PAMELA. As described previously,
the implementation of the authentication pattern is
based on three classes AuthenticatorPatternFac-
tory, AuthenticatorPatternDefinition and Au-
thenticatorPatternInstance to define the secu-
rity contract the authentication service. First, each
attribute of the AuthenticatorPatternDefinition
class has a corresponding annotation; the figure 2 il-
lustrates the left part of the figure. After the definition,
these annotations are directly used in the code that we
want to assume an Execution under Contract.
The Manager is only illustrative to clearly demon-
strate which instance of the Manager class plays the
Authenticator role (in the pattern description), while
an instance of the Client class plays the Subject role.
Security Contracts a Property-Based Approach to Support Security Patterns
105

manager
0..1
P1: ∀𝑎,𝑏 ∈ 𝐼𝑆𝑢𝑏𝑗𝑒𝑐𝑡,
𝑎≠𝑏=⇒𝑎.𝑎𝑢𝑡ℎ𝐼𝑛𝑓𝑜≠𝑏.𝑎𝑢𝑡ℎ𝐼𝑛𝑓𝑜
P2 : ∀𝑎 ∈ 𝐼𝑆𝑢𝑏𝑗𝑒𝑐𝑡, 𝑎.𝑎𝑢𝑡ℎ𝐼𝑛𝑓𝑜=𝑎.𝑎𝑢𝑡ℎ𝐼𝑛𝑓𝑜𝑖𝑛𝑖
P3 : ∀𝑎 ∈ 𝐼𝑆𝑢𝑏𝑗𝑒𝑐𝑡,
𝑎.𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑜𝑟=𝑎.𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑜𝑟𝑖𝑛𝑖
P4 : ∀𝑎 ∈ 𝐼𝑆𝑢𝑏𝑗𝑒𝑐𝑡, (𝑎.𝑖𝑑𝑃𝑟𝑜𝑜𝑓=∅) ∨
(𝑎.𝑖𝑑 𝑃𝑟𝑜𝑜𝑓 =
𝑎.𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑜𝑟.𝑟𝑒𝑞𝑢𝑒𝑠𝑡(𝑎.𝑎𝑢𝑡ℎ𝐼𝑛𝑓𝑜))
P5 : 𝑠𝑒𝑙𝑓.𝑖𝑑𝑃𝑟𝑜𝑜𝑓 =
𝑠𝑒𝑙𝑓.𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑜𝑟.𝑟𝑒𝑞𝑢𝑒𝑠𝑡(𝑠𝑒𝑙f.𝑎𝑢𝑡ℎ𝐼𝑛𝑓𝑜)
P6 : 𝑠𝑒𝑙f.𝑐ℎ𝑒𝑐𝑘(𝑎𝑢𝑡ℎ𝐼𝑛𝑓𝑜) ∨ 𝑟𝑒𝑡𝑢𝑟𝑛𝑉𝑎𝑙𝑢𝑒 = ∅
*
Client
+ authenticate()
- manager
- authInfo
- IDProof
Manager
+ int request(String id)
AuthenticatorPatternDefinition
Subject
- authenticatorGetterMethod
Authenticator
- requestAuthenticationMethod
- authenticationInfoMethod
- proofOfIdentitySetterMethod
- authenticateMethod
myManager
myClient
instance of
AuthenticatorPatternInstance
PAME LA i nt er pr et er
Design time
Runtime
<<creates>
<<uses>>
instance of
Figure 2: PAMELA vision of the Authenticator pattern.
At runtime, both functional code and security contract
logic, i.e. pattern class behavior and contract enforce-
ment, are weaved by the PAMELA framework. This
allows, for instance, for the contract properties to be
checked at runtime before and/or after any method
of interest. In the case of the Authenticator pattern,
the AuthenticatorPatternInstance objects will
check the invariants of the pattern contract before and
after every call to Subject and Authenticator classes.
The mapping is summarized in Figure 2.
Note that the contract user only needs to annotate
his code and PAMELA will automatically handle the
pattern business logic (both, pattern behavior and as-
sertion checking). For more details on this example,
we direct the reader to our previous paper (Silva et al.,
2020).
Our tooling includes a security contract library
ready for deployment by application developers in
their source code. As of now, this library includes
the following contracts: Authenticator, Authoriza-
tion, Single access point, Owner, Role-based access
control
Details about these patterns and how to use them
are available on the project’s Web site
1
.
4 USE CASE: APPLYING
SECURITY CONTRACT TO
EXISTING CODE
To demonstrate the effectiveness of security con-
tracts, we apply them to an existing and widely used
framework, the Open Source Spring framework
2
. We
selected this framework due to the worldly use for
1
https://www.openflexo.org/pamela/docs/category/security-
features/
2
https://github.com/spring-projects/spring-framework
web’s application backend. This intensive use is sup-
ported by the Java language with its strong typed sys-
tem.
The Open Source status of this framework pro-
vides an excellent use case to tackle our Security Con-
tracts related to both the reuse of legacy code and on
the Authentication process to ensure an efficient first
shield.
4.1 The Spring Framework
Spring is a framework for developing Web applica-
tions and is based on predefined libraries that include
reusable classes. In terms of security, the exten-
sion possibilities of this framework can be problem
sources in terms of understanding and by untimely
addition of bugs or vulnerabilities. Spring has a
web module that supports the Servlet API (which dy-
namically creates data within an HTTP server) called
Spring MVC for Model View Controller.
Spring Security is the library that includes the
management of authentication and access control.
Like any Spring project, it is customizable. Authenti-
cation being the first security rampart of the applica-
tion, the issue here is to make sure that this Authen-
ticator design pattern preserves the desired security
properties. This requirement has guided our experi-
ment to focus on the application of Security Contracts
on the authentication process.
Figure 3 details the authentication management
within the Spring framework. A generic scenario is
explained in the figure through the diagram numbers.
So when the application developed with Spring Secu-
rity receives a request(1), a component chain is acti-
vated. When the request contains an authentication
one, the AuthenticationFilter will extract the user’s
credentials (usually username and password) and cre-
ate an Authentication object. If the information re-
ceived contains a correct username and password, a
UsernamePasswordAuthenticationToken will be cre-
ated containing the username and the password (2).
This token will be used to invoke the authen-
ticate() method of AuthenticationManager which is
implemented by ProviderManager (3). There are sev-
eral AuthenticationProvider already configured and
listed in ProviderManager. The one we will use
in this experiment is the DAOAuthenticationProvider.
DAO stands for ”Data Access Object”, which is
a model that provides an abstract interface to a
database type. By mapping application calls to
the persistence layer, the DAO provides certain spe-
cific data operations without exposing the details of
the database. The DAOAuthenticationProvider uses
UserDetailsService (5) to retrieve user data based on
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
106

the user’s username (6) , (7) , (8) , (9). If the au-
thentication (10) succeeds, then the complete Authen-
tication object (with ”authenticated = True”, the list
of authorities and the user name) is returned. Fi-
nally, the AuthenticationManager returns the Authen-
tication object to the Authenticationfilter, the authen-
tication has succeeded, and the object is stored in the
SecurityContext. And if authentication fails, the Au-
thenticationManager raises an exception Authentica-
tionException will be thrown.
AuthenticationFilter
UsernamePassword
AuthenticationToken
AuthenticationManager
"interface"
ProviderManager
AuthenticationProvider
AuthenticationProvider
AuthenticationProvider
UserDetailsService
UserDetails
"interface"
SecurityContextHolder
SecurityContext
Authentication
1
2
3 4
5
6
7
8
9
10
implementes
HTTP
request
Figure 3: Authenticate service in the Spring framework.
4.2 Applying the Authenticator Security
Contract on the Spring
Authentication
The implementation of the Security Contract Authen-
ticator in this context is based on two phases: 1)
Weaving the Authenticator pattern entities into the
Spring architecture, presented just below 2) Allocat-
ing the security properties, presented in the section
3.1, to be preserved by the application.
These two steps are ensured by source code anno-
tation techniques.
Based on the class diagram of the Authenticator
of the figure 1, the contract identifies four distinct
entities: Authenticator, Subject, AuthenticationInfor-
mation and ProofOfIdentity, for which we need to
find the corresponding business concept in the Spring
source code to be annotated. To examplify our ap-
proach, for this paper we select only the Authentica-
tor and the Subject entities. Note that the full code of
this use case can be found on the project web site
3
.
4.2.1 Authenticator
This concept is identified in the Authenticator pat-
tern with the @Authenticator annotation. On the
application to secure, the Java interface Authentica-
tionProvider plays the corresponding role. So this
role is applied, line 3 of the listing 1, to the special-
3
https://github.com/openflexo-
team/pamela/tree/2.0/pamela-spring-security-uc
1 @ModelEntity
2 @ImplementationClass(
CustomAuthenticationProviderImpl.class )
3 @Authenticator(patternID = SessionInfo .
PATTERN ID)
4 @Imports(@Import(SessionInfo.class) )
5 public interface CustomAuthenticationProvider
extends AuthenticationProvider {
6 String USER NAME = ”userName”;
7 // Inherited from AuthenticationProvider API
8 public Authentication authenticate (
Authentication authentication ) throws
AuthenticationException ;
9 ...
10 abstract class CustomAuthenticationProviderImpl
extends DaoAuthenticationProvider
implements CustomAuthenticationProvider {
11 @Override
12 public Authentication authenticate (
Authentication authentication ) throws
AuthenticationException {
13 ...
14 }
15 @Override
16 public UsernamePasswordAuthenticationToken
request( String userName) {
17 ...
18 }
19 }
20 }
Listing 1: CustomAuthenticationProvider definition.
ization CustomAuthenticationProvider which extends
AuthenticationProvider.
From an implementation point of view, the role is
implemented by the CustomAuthenticationProvider-
Impl class, presented on line 10 in the listing 1. This
class extends the DAOAuthenticationProvider class
that takes care of this role in the Spring framework.
The link between the role and the pattern
definition is done via the identifier Session-
Info.PATTERN
ID, which is currently a character
string, but must evolve in a unique URI; see line 3
listing 1.
4.2.2 Subject
This concept is identified in the Authenticator pat-
tern with the @AuthenticatorSubject annotation,
line 3 of the listing 2. On the Spring source code,
this concept is not directly reified, but corresponds to
the notion of session from our point of view. Thus,
we reify the concept SessionInfo, which is pre-
sented in the listing 2 and allows the management
of the user name (authentication information), IP ad-
dress, and proof of identity from lines 6 to 16, as
well as the access to the authenticator via the acces-
sors getAuthenticationProvider() and setAu-
thenticationProvider().
Security Contracts a Property-Based Approach to Support Security Patterns
107

1 @ModelEntity
2 @ImplementationClass(SessionInfo.SessionInfoImpl .
class )
3 @AuthenticatorSubject( patternID = SessionInfo .
PATTERN ID)
4 public interface SessionInfo {
5 String PATTERN ID = ”AuthenticatorPattern”;
6 @Getter(USER NAME)
7 @AuthenticationInformation( patternID =
PATTERN ID, paramID =
CustomAuthenticationProvider.USER NAME)
8 String getUserName();
9 @Setter(USER NAME) void setUserName(String
val);
10 @Getter(IP ADRESS) String getIpAdress();
11 @Setter(IP ADRESS) void setIpAdress(String val ) ;
12 @Getter(value = ID PROOF, ignoreType = true)
13 UsernamePasswordAuthenticationToken
getIDProof();
14 @Setter(ID PROOF)
15 @ProofOfIdentitySetter ( patternID = PATTERN ID
)
16 void setIdProof (
UsernamePasswordAuthenticationToken value);
17 @Getter(AUTHENTICATION PROVIDER)
18 @AuthenticatorGetter( patternID = PATTERN ID)
19 CustomAuthenticationProvider
getAuthenticationProvider () ;
20 @Setter(AUTHENTICATION PROVIDER)
21 void setAuthenticationProvider (
CustomAuthenticationProvider val ) ;
22 ....
23 @AuthenticateMethod(patternID = PATTERN ID)
24 void authenticate () ;
25 @RequiresAuthentication
26 void checkSecure() ;
27 abstract class SessionInfoImpl implements
SessionInfo {
28 // implementation code of checkSecure()
and getIpAdress ()
29 }
30 }
Listing 2: SessionInfo entity implementation.
The method authenticate() (line 24 of the
listing 2 is identified via the annotation @Authen-
ticateMethod to the method request of the pat-
tern Authenticator as presented in Figure 2. The
checkSecure() method is annotated as @Require-
sAuthentication, line 25-26, to trigger the Authen-
tication process based on the method with the anno-
tation @AuthenticateMethod if the process is exe-
cuted for the first time.
4.2.3 Authentication Management
The management of the authentication itself is intri-
cated because of two competing levels: the authenti-
cation provided by the Spring framework and the one
implemented in our Authenticator pattern. The align-
ment of the two mechanisms takes place in the im-
plementation of CustomAuthenticationProvider-
Impl (listing 3). The Spring framework receives the
authentication requests via the call of the method
authenticate(Authentication) of Authentica-
tionProvider. We overwrite this method, line 11,
with the management of the current session informa-
tion (from lines 13 to 25), and the authenticate()
and checkSecure() of the SessionInfo entity, lines
21 to 24, guarantees the use of the security pattern to
ensure contract properties.
4.3 A Temporal Logic Property on a
Authenticator Pattern Specialisation
One of the interests of our approach lies in the abil-
ity of the framework to provide extension points.
In our case, the CustomAuthenticationProvider
class specializes in the Authenticator pattern.
The second feature of our framework that we ex-
ploit is the reification of the notion of instance of
the Authenticator pattern through the instance of the
AuthenticatorPatternInstance class. This class
encapsulates the instances of the subject (class Ses-
sionInfo) and authenticator (class CustomAuthen-
ticationProvider). As this class gives access to
the instances of the classes of the pattern, an intro-
spection capacity of the current state of the pattern is
provided during all its life cycle.
We have taken advantage of these two aspects to
specialize the Authenticator pattern by extending the
behavior with a new temporized temporal property.
This property takes into account a time quantity ap-
plied on an execution path of the pattern. Classically,
this property expresses the fact that there cannot be
more than three authentication failures in a given pe-
riod of time. If three failures occur in this period,
the application will have to switch to another mode,
for example, refusing any authentication attempt for a
certain time, for example.
Let auth f ail
i
be an ”authentication failure” event
for the property specification in the current execution
trace:
P7:∀{auth f ail
i
,auth f ail
i+1
,auth f ail
i+2
}∈execution trace
auth f ail
i+2
.time−auth f ail
i
.time<T IME LIMIT
The class CustomAuthenticatorPatternIn-
stance, listing 4, implements the definition of the
property P7 through the method checkRecentAu-
thFailCountLessThan3 from lines 7 to 15. This
property is based on the evaluation of the events
variable, defined line 3, which is defined as an
instance variable of this class. This variable events
embodies the current state of the class’s instances
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
108

1 abstract class CustomAuthenticationProviderImpl
extends DaoAuthenticationProvider implements
CustomAuthenticationProvider {
2 private Map<String,
UsernamePasswordAuthenticationToken>
tokens
3 = new HashMap<>();
4 /
**
Implementation is here trivial as we use
map filled by
5
*
{@link # authenticate ( Authentication )}
method
*
/
6 @Override
7 public UsernamePasswordAuthenticationToken
request( String userName) {
8 return tokens . get(userName);
9 }
10 @Override
11 public Authentication authenticate (
Authentication authentication ) throws
AuthenticationException {
12 try {
13 UsernamePasswordAuthenticationToken
returned = (
UsernamePasswordAuthenticationToken)
super. authenticate ( authentication ) ;
14 String name = authentication . getName();
15 WebAuthenticationDetails details = (
WebAuthenticationDetails )
authentication . getDetails () ;
16 String userIp = details .getRemoteAddress();
17 SessionInfo sessionInfo = SessionInfo .
getCurrentSessionInfo () ;
18 sessionInfo . setUserName(name);
19 sessionInfo . setIpAdress ( userIp ) ;
20 tokens . put (name, returned ) ;
21 // Call authenticate () to complete process
22 sessionInfo . authenticate () ;
23 // Ensure that we are now in authenticated
context
24 sessionInfo . checkSecure() ;
25 return returned ;
26 } catch ( AuthenticationException e) {
27 throw e;
28 } catch (ModelExecutionException e) {
29 e. printStackTrace () ;
30 throw new SessionAuthenticationException (”
Exception during authentication : ” + e .
getMessage()) ;
31 }
32 }
33 }
Listing 3: CustomAuthenticationProviderImpl
implementation.
and is part of the global state of the pattern. In our
example, this variable is updated, line 17, to take into
account each authentication failure, and so assessed
for the property evaluation.
After the definition of the contract property, the
listing 5 presents the definition of the Authentica-
tor referring to this property as a precondition of the
1 public class CustomAuthenticatorPatternInstance extends
AuthenticatorPatternInstance<CustomAuthenticationProvider,
SessionInfo, String, UsernamePasswordAuthenticationToken> {
2 public static long TIME_LIMIT = 180000; // 180s = 3 min
3 private List<PatternInstanceEvent> events = new ArrayList<>();
4 public CustomAuthenticatorPatternInstance(
CustomAuthenticatorPatternDefinition patternDefinition,
PamelaModel model, SessionInfo subject) {
5 super(patternDefinition, model, subject);
6 }
7 // Perform check that last 3 AuthFailEvent in current time limit
8 public boolean checkRecentAuthFailCountLessThan3() {
9 long currentTime = System.currentTimeMillis();
10 if (events.size() >= 3 && (currentTime - events.get(events.
size() - 3).getDate()) < TIME_LIMIT) {
11 // 3 attempts or more in TIME_LIMIT interval
12 return false;
13 }
14 return true;
15 }
16 public void generateAuthFailEvent() {
17 events.add(new AuthFailedEvent());
18 }
19 .......
20 }
Listing 4: CustomAuthenticatorPatternInstance
implementation.
1 public interface CustomAuthenticationProvider extends
AuthenticationProvider {
2 ...
3 @Override
4 @OnException(
5 patternID = SessionInfo.PATTERN_ID,
6 onException = AuthenticationException.class,
7 perform = "patternInstance.generateAuthFailEvent()",
8 strategy = OnExceptionStategy.HandleAndRethrowException)
9 @Ensures(patternID = SessionInfo.PATTERN_ID, property = "
patternInstance.checkRecentAuthFailCountLessThan3()")
10 public Authentication authenticate(Authentication
authentication) throws AuthenticationException;
11 ...
12 }
Listing 5: CustomAuthenticationProvider implementation.
method authenticate() with an @Ensures annota-
tion with property P7 as parameter, line 9. Also, we
can see between the lines 4 and 8, the use of the anno-
tation @OnException which allows to automatically
generate events corresponding to the failure of con-
nection. This event is stored in the pattern state via
the events variable as we described before.
The P7 annotation is defined related to the au-
thenticate() method. So, for now, any call to
this method respects the security contract defined
by the instance CustomAuthenticatorPatternIn-
stance corresponding to the current execution. This
contract automatically handles the AuthFailedE-
vent event and checks that a user cannot fail to au-
thenticate more than 3 times in a given time.
5 RELATED WORK
To the best of our knowledge, ours is the first ap-
proach aimed at extending the Design by Contract
paradigm to the specification and run-time monitoring
of Security Contracts. The limit of classical contracts
for the monitoring of patterns and properties that re-
Security Contracts a Property-Based Approach to Support Security Patterns
109

quire context knowledge was already acknowledged
in (Hallstrom et al., 2004) and (Ostroff et al., 2009)
which served as inspiration for our work.
Formal definitions of security patterns are pro-
vided by several authors (Cheng et al., 2019),
(Behrens, 2018), (Da Silva J
´
unior et al., 2013). The
purpose of these formal definitions is to analyze the
behavior of the patterns at design level or to enable
automatic analysis operations. On the contrary, our
proposal to formalize security patterns with a Design
by Contract approach aims at ensuring a secure im-
plementation of the patterns. Thus, we can see these
approaches as complementary.
More related to the implementation level,
in (Mongiello et al., 2015), the authors propose AC-
contract, an approach for the run-time verification
of (adaptive) context-aware applications. It uses
pre-defined patterns in order to derive contracts on
components which are verified at run-time depending
on a set of event and states. Compared to ours, apart
from implementations details (e.g., their approach
integrate contract components in separate XML docu-
ments), their approach is more coarse-grained (works
at the component level), focuses in self-adaptation,
and does not deal with security. Close to our work
from an implementation point of view, in (Hallstrom
et al., 2004) the authors propose an AoP approach to
monitor pattern contracts. Each pattern contract is
associated with a dedicated pattern and is defined in
an aspect. This aspect is used to monitor, at run-time,
the applied pattern. Nevertheless, this approach is
focused exclusively on the implementation without
a will to provide abstraction related to the contract
definition. Note that none of the aforementioned
approaches focuses on security. In (Dikanski et al.,
2012), the authors evaluate Spring Security in order
to identify existing security patterns to provide a
mapping with Spring security mechanisms. However,
they do not provide any supporting mechanism for
implementation or monitoring of the patterns.
6 CONCLUSION & FUTURE
WORK
In this paper we have presented Security Contracts, a
novel extension of the Design by Contract paradigm
aimed at supporting security patterns. Our approach
provides a mechanism for the specification of re-
usable and extensible abstract patterns, their deploy-
ment on host applications and their monitoring at run-
time, in what we call, Execution under Contract. A
prototype implementation for the Java ecosystem and
its application to a case study involving the enhance-
ment of the authentication mechanism provided by
the Spring Security framework are presented as well.
Concretely, we have shown how we can define the
Authenticator pattern as a Security Contract in an
abstract way, deploy it by the means of annotations
in both new and existing applications and monitor
and enforce its properties (including temporal ones)
at run-time.
As future work we envision the exploration of the
following research lines: 1) Pattern composition. We
intend to investigate an extension of our framework in
order to give support to the composition of patterns.
This will enable the possibility of creating complex
patterns as a composition of simpler, easier to ver-
ify ones. 2) Annotation enhancement. We aim to
research the feasibility of the integration of a given
(temporal) logic directly in the annotations used to
deploy the pattern, so that the user can add/modify
its properties.
ACKNOWLEDGMENTS
The authors thank Caine Silva and Henri Stoven for
their help in this work.
REFERENCES
Behrens, A. (2018). What are security patterns? a formal
model for security and design of software. In Proceed-
ings of the 13th International Conference on Avail-
ability, Reliability and Security, pages 1–6.
Cheng, B. H., Doherty, B., Polanco, N., and Pasco, M.
(2019). Security patterns for automotive systems. In
2019 ACM/IEEE 22nd International Conference on
Model Driven Engineering Languages and Systems
Companion (MODELS-C), pages 54–63. IEEE.
Da Silva J
´
unior, L. S., Gu
´
eh
´
eneuc, Y.-G., and Mullins, J.
(2013). An approach to formalise security patterns.
Technical report, Citeseer.
Dikanski, A., Steinegger, R., and Abeck, S. (2012). Identi-
fication and implementation of authentication and au-
thorization patterns in the spring security framework.
In The Sixth International Conference on Emerging
Security Information, Systems and Technologies (SE-
CURWARE 2012), pages 14–30.
Fernandez, E. B., Yoshioka, N., Washizaki, H., and Yoder,
J. (2018). An abstract security pattern for authenti-
cation and a derived concrete pattern, the credential-
based authentication. In Asian pattern languages of
programs conference (AsianPLoP).
Fernandez-Buglioni, E. (2013). Security patterns in prac-
tice: designing secure architectures using software
patterns. John Wiley & Sons.
Gu
´
erin, S., Polet, G., Silva, C., Champeau, J., Bach,
J.-C., Mart
´
ınez, S., Dagnat, F., and Beugnard, A.
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
110

(2021). PAMELA: an annotation-based Java Model-
ing Framework. Science of Computer Programming.
Hallstrom, J. O., Soundarajan, N., and Tyler, B. (2004).
Monitoring design pattern contracts. In Proc. of the
FSE-12 Workshop on Specification and Verification of
Component-Based Systems, pages 87–94.
Johnson, R., Hoeller, J., Donald, K., Sampaleanu, C.,
Harrop, R., Risberg, T., Arendsen, A., Davison, D.,
Kopylenko, D., Pollack, M., et al. (2004). The
spring framework–reference documentation. inter-
face, 21:27.
Meyer, B. (1992). Applying’design by contract’. Computer,
25(10):40–51.
Mongiello, M., Pelliccione, P., and Sciancalepore, M.
(2015). Ac-contract: Run-time verification of context-
aware applications. In 2015 IEEE/ACM 10th Interna-
tional Symposium on Software Engineering for Adap-
tive and Self-Managing Systems, pages 24–34. IEEE.
Ostroff, J. S., Torshizi, F. A., Huang, H. F., and Schoeller,
B. (2009). Beyond contracts for concurrency. Formal
Aspects of Computing, 21:319–346.
Schumacher, M., Fernandez-Buglioni, E., Hybertson, D.,
Buschmann, F., and Sommerlad, P. (2013). Security
Patterns: Integrating security and systems engineer-
ing. John Wiley & Sons.
Silva, C., Gu
´
erin, S., Mazo, R., and Champeau, J. (2020).
Contract-based design patterns: a design by contract
approach to specify security patterns. In Proceedings
of the The 6th International Workshop on Secure Soft-
ware Engineering SSE@ARES, pages 1–9.
Yoshioka, N., Washizaki, H., and Maruyama, K. (2008). A
survey on security patterns. Progress in informatics,
5(5):35–47.
Security Contracts a Property-Based Approach to Support Security Patterns
111