Risk Management for Dynamic Metadata Exchange

via a Trusted Third Party

Daniela P

ohn

Leibniz Supercomputing Centre, Boltzmannstr. 1, Garching n. Munich, Munich, Germany

Keywords:

Federated Identity Management, Metadata, SAML, Metadata Exchange.

Abstract:

Inter-organizational access to IT services based on the predominant standard of Federated Identity Manage-

ment (FIM), the Security Assertion Markup Language (SAML), suffers from scalability issues related to

metadata exchange. In order to overcome these issues, an approach for automated metadata exchange be-

tween Identity Provider (IDP) and Service Provider (SP) via a Trusted Third Party (TTP) is presented in this

article. Based on the architecture, risk management with threats and counter measures is applied by using a

risk management template. Special emphasis is put on the secure design of the automated metadata exchange.

1 INTRODUCTION

Medium-sized and large organizations, like universi-

ties and companies, typically provide several infor-

mation and communications technology (ICT) ser-

vices to their members. These can be, e. g., email,

web collaboration tools, and more speciﬁc services,

like exam management service. In order to authen-

ticate, a technical identiﬁer, commonly referred as

username, is assigned to each member. By provid-

ing the username and credentials, the user gets access

to these services. While the local, normally central-

ized Identity & Access Management (I&AM) enables

organization wide solution for identity management,

this becomes more complex when several organiza-

tion collaborate.

Such a collaboration can be a research project or

a combined development of a product, reducing the

costs for all participating companies. In order to

store and manage the user information only at one

place, Federated Identity Management (FIM) was es-

tablished. It is either based on the trust all comers

principle of OAuth (Hardt, 2012) and OpenID Con-

nect (Sakimura et al., 2014), as many web appli-

cations do, like Facebook and Google just to name

two. The other possibility is the usage of Security

Assertion Markup Language (SAML) (Cantor et al.,

2005a), which has closed trust boundaries. SAML

is used in the Research & Education environment as

well as in companies, like in the automotive federa-

tion Odette SESAM (Odette, 2009). The home or-

ganization of the user is called within SAML-world

– as well as in this paper – Identity Provider (IDP),

while the provider of the service is referred to as Ser-

vice Provider (SP). A formally collaboration of IDPs

and SPs is called a federation. In research and educa-

tion, these federations operated by national research

and education networks (NRENs) can include hun-

dreds to thousands of universities and research insti-

tutions with all their students, staff, and researchers.

Examples of those NREN federations are DFN-AAI

in Germany (DFN-AAI, 2015) and InCommon in the

US (InCommon, 2015).

Although these speciﬁc federations by geography

and industry-sector are not imposed by FIM technol-

ogy and protocols, it has become a reality. Most

countries and sectors run their own federation. In

order to cooperate internationally, so called inter-

federations are built, still excluding several potential

members. Let’s assume a researcher is involved into a

research community, also called virtual organization,

which provides several services essential for his work.

The organizations participating in the community are

spread over the world. At the same time, the univer-

sity of the researcher, also called IDP, is member of

a national federation. Other IDPs and SPs are part

of this national federation, in order to make use of

FIM. As common protocol, they use SAML as it has

ﬁxed trust boundaries in comparison to OpenID Con-

nect. In order to know the endpoints and to have a cir-

cle of trust, they pre-exchange their metadata (Cantor

et al., 2005b). Metadata includes information about

the information endpoints, but also contact informa-

tion, and required attributes. In SAML-world, IDP

Pöhn, D.

Risk Management for Dynamic Metadata Exchange via a Trusted Third Party.

DOI: 10.5220/0005651702270234

In Proceedings of the 2nd International Conference on Information Systems Security and Privacy (ICISSP 2016), pages 227-234

ISBN: 978-989-758-167-0

227

and SP can only make use of FIM, when they have

each others metadata. Although SAML does not ex-

plicitly specify the pre-exchange of aggregated meta-

data, it is current practice. Since the national federa-

tion is member of an inter-federation, e. g., eduGAIN,

the metadata of all members of the inter-federation is

as well aggregated and then distributed. In the case

of eduGAIN this comprises 40 federations with more

than 2,000 entities (G

EANT, 2015). As a result, ser-

vices can only be used within these trust boundaries.

This also means that the researcher’s virtual organiza-

tions need to set up their own virtual federation, as not

all members are participating in the inter-federation,

or it needs to make use of a Homeless IDP, integrating

all users from outside the inter-federation.

This example explains the main problems of FIM

with SAML. Although FIM is widely used, the cover-

age and scalability are known issues. The size of the

aggregated metadata is increasing, when more fed-

erations and providers are participating. The imple-

mented solutions are only sector-wide, e. g., Odette

SESAM in the automotive industry, while eduGAIN

is used in NREN federations. The approach the inter-

federation eduGAIN uses comes to its boundaries, as

the approach is not scalable. The aggregators and

parsers for the metadata can hardly cope with the in-

creasing amount of data. Since more and more ser-

vices are offered on-demand, the practical problem

and relevant question is, if the SAML metadata, re-

quired to make use of FIM, can be exchanged securely

on-demand. This article adds security considerations

and a risk management based on a template to the

EANT-TrustBroker approach (P

ohn et al., 2014).

The new approach, initiated by the eduGAIN oper-

ators (G

EANT project), needs to be as secure as FIM

with SAML can be, even though new components and

workﬂows are introduced.

The following section contrasts the architecture of

a Trusted Third Party (TTP) for dynamic metadata ex-

change with current state of the art and practical ap-

proaches. Section 3 explains a template for risk man-

agement, which is applied to the approach of dynamic

metadata exchange via a TTP in the following sec-

tions. Section 4 describes possible threats for the TTP,

while Section 5 characterizes actors against the TTP.

The following Section 6 describes counter measure-

ments, which need to be taken into account during the

implementation and the operations. Last but not least,

the paper concludes in Section 7 with the results and

further research questions.

2 DYNAMIC METADATA

EXCHANGE VIA A TTP

In order to help administrators with the management

of their metadata, the Swiss federation SwitchAAI

was the ﬁrst NREN federation to develop a web ser-

vice called Resource Registry. The Resource Reg-

istry lets entities register their metadata and update

entity information, before the national metadata ﬁle

is aggregated and distributed, based on all uploaded

metadata ﬁles. Further NREN federations adapted

this solution. A newer practical solution is the Pub-

lic Endpoint Entities Registry (PEER) by Young et

al. (Young and Joie, 2009). The concept of PEER

and the implementation called REEP is that any en-

tity, independent of the federation and protocol, can

use the registry. Therefore, it shifts from several

federations-several tools to one central tool, whereas

the metadata is still aggregated by federations and

inter-federations. Furthermore, manual steps are re-

quired to exchange metadata.

The approach of a TTP for dynamic metadata ex-

change works similar to PEER, as any entity can reg-

ister and upload their metadata. Alternatively, they

can set a pointer to their local metadata location,

which is public. In order to establish technical trust

on-demand, the TTP extends a localization service.

The service, formally known as WAYF (Where Are

You From?), is used to localize the user’s IDP and

therefore knows both endpoints of the metadata ex-

change. The user wants to make use of a service, i. e.,

he expresses his will to access a speciﬁc service at a

SP. By that, if IDP and SP technically do not know

each other, the TTP triggers the metadata exchange

on-demand. This approach is also described in (P

ohn

et al., 2014), where the state of the art, basic concepts,

workﬂows, and database design were explained. As

only the necessary metadata is exchanged, this signif-

icantly improves the scalability of the metadata ex-

change, while at the same time avoids performance

bottlenecks.

Young submitted an Internet-Draft (I-D) called

Metadata Query Protocol (Young, 2015). Another

I-D, SAML Proﬁle for the Metadata Query Proto-

col, describes the proﬁle for SAML. By the Metadata

Query Protocol, metadata can be retrieved by sim-

ple hypertext transfer protocol (HTTP) GET requests.

This theoretically allows dynamic metadata distribu-

tion.

The TTP can re-use the Metadata Query Protocol, let-

ting IDPs and SPs query metadata on-demand. Either

the TTP knows the metadata location at the entity or

it stores it in a metadata repository. The authenticated

user triggers the metadata exchange by an extended

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

228

IDP discovery workﬂow based on SAML, as speciﬁed

in the I-D Dynamic Automated Metadata Exchange

(DAME) (P

ohn, 2015a). The TTP orchestrates the

metadata exchange, while the exchange itself can be

done by the Metadata Query Protocol.

Similar to the described TTP, the approach Trust

Service Provider (TSP) by Jian Jiang et al. (Jiang

et al., 2011) requires each entity to register at the cen-

tral TSP service. The TSP brokers the trust of two

entities during runtime. The metadata is downloaded

from the TSP and might be stored in the cache of an

entity. If a user wants to make use of a service, the SP

needs to query his local cache about the metadata of

the IDP. If the SP does not have the needed metadata,

it sends a request to the TSP. The IDP is required to

send another request, in order to fetch the metadata of

the SP. The metadata ﬁles have version numbers. If

the IDP is outside the federation, the SP of the home

federation of the IDP can be used as an IDP-Proxy for

indirect authentication. This also means, that the SP

needs to cache the assertion of the home IDP and that

each SP needs to run an IDP-Proxy. Additionally, the

version number is unnecessarily added to the meta-

data’s name.

The TTP, in contrast, does not need version numbers

and IDP-Proxys, as every federation and entity can

a distributed version of the TTPs, which communi-

cate with each other and exchange metadata across

TTPs. Therefore, entities do only need to register

once. The approach of the TTP automates the tech-

nical integration of new metadata on the SP as well as

on the IDP side. In order to integrate these informa-

tion automatically, an extension of existing software

is needed. The extension of the software can auto-

mate the manual steps by the information already in-

cluded into the metadata. This eliminates the manual

workload for SP and IDP administrators and avoids

waiting time for the end users. This is particularly the

case as the metadata can be exchanged across current

federations’ boarders.

The approach Dynamic Identity Federation by

Md. Sadek Ferdous and Ron Poet (Ferdous and

Poet, 2013) concentrates on the dynamic trust. Dy-

namic Identity Federation distinguishes between fully

trusted, semi-trusted, and untrusted entities. Authen-

ticated users are allowed to add SPs to their IDPs,

while SPs add the IDPs to their local trust anchor

list (TAL) for further usage. The user establishes the

trust by generating a code at his ﬁrst authentication.

He then informs the SP about the code and the Enti-

tyID of the IDP. After veriﬁcation, the SP generates

a request with two invisible ﬁelds, i. e., MetaAdd and

ReturnTo. Both ﬁelds are used for the metadata ex-

change, while the IDP needs to evaluate the value of

MetaAdd. When the user gives his consent, the IDP

adds the chosen SP to the list of semi-trusted entities.

Semi-trusted entities are not allowed to receive sen-

sitive attributes. Untrusted entities are given the Na-

tional Institute of Standards and Technology (NIST)

level of assurance (LoA) 1. If the SP is not known by

the IDP, a proxy could be used complicating the trust

establishment. The trust establishment via the user

generating and forwarding a code is not user friendly,

while both invisible ﬁelds are not necessary. The frag-

mentation into trusted, semi-trusted, and untrusted en-

tities as well as the usage of NIST LoA 1 does not

reﬂect real world with its different LoA schemes and

the trust relationships. As with the IDP discovery ser-

vice, all relevant information are integrated within the

SAML messages, additional ﬁelds are not required.

If the user trusts an SP, the SP is added to the IDP’s

TAL, which consists of all downloaded and integrated

metadata. If this fully automated trust is not wanted,

the IDP and SP can conﬁgure their LoA and the level

they want from their counterpart. If, e. g., the IDP

matches the level required by the SP, the metadata is

exchanged on-demand, while otherwise the adminis-

trators and the user are notiﬁed. Since many differ-

ent LoA are used within federations and most NREN

federation have around NIST LoA 1 or 2, a more ﬁne-

grained LoA schema is needed, which can also map

different schemes. Furthermore, a federation admin-

istration tool is implemented for additional quality as-

surance.

Summing up, the TTP is a central service for on-

demand metadata exchange for IDPs and SPs. It

allows scalable metadata exchange, which is user

triggered and based on standard SAML workﬂows.

By software extensions it automates manual work-

ﬂows and widens the trust boundaries, while, at the

same time, providing tools for quality assurance and

trust assurance. As the TTP is not an IDP proxy,

it is not involved in further communication. This

also reduces the likelihood of a bottleneck. Fur-

thermore, it could be operated distributively, as de-

scribed in (P

ohn, 2015b). The theoretical approach

of a TTP is currently implemented and improved for

piloting within the project G

EANT, which runs the

inter-federation eduGAIN. In order to have a secure

implementation and all needed functions, the risk and

security management is regarded. While the proof

of concept implementation of the TTP is tailored for

SAML, the TTP and all its functionalities are generi-

cally designed, so it can be adopted to further proto-

cols without changes.

For the researcher described above, it means that

his IDP and all the SPs of the community have to reg-

Risk Management for Dynamic Metadata Exchange via a Trusted Third Party

229

ister at the TTP as a prerequisite. If the researcher

wants to use a new service of the community, he is

forwarded to the extended discovery service of the

TTP. By choosing his IDP, he automatically triggers

the metadata exchange between IDP and SP. Since

both have conﬁgured fully automated metadata ex-

change and their LoA is high enough, the metadata

is exchanged on-demand and directly integrated into

the local conﬁguration. The researcher therefore does

not have to wait until he can access the service. In

order to have the researcher securely access the ser-

vice, the risk and security of the new components has

to be regarded, before it is piloted within the G

EANT

project.

3 RISK MANAGEMENT

In order to achieve a technology readiness level TRL7

and following existing good practices and interna-

tional standards, e. g., ISO/IEC 27001, a risk assess-

ment takes place. Hommel et. al (Hommel et al.,

2015) present a risk management template, which

operationalizes and supports the continuous manage-

ment process. This risk management template was

applied to the TTP. As the TTP allows the automated

metadata exchange, which possibly leads to the re-

lease of personally identiﬁable information, the crit-

ically has to be set to high. Therefore, appropriate

security measures have to be implemented.

The ﬁrst step of risk management is the deﬁnition

of primary and secondary assets. The secondary as-

sets and the operational risk management are regarded

in Section 4. Possible events threatening components

of the dynamic metadata exchange are, e. g., ﬂood-

ing the TTP with metadata exchange requests, as de-

scribed above. Assessing the threat event, the likeli-

hood as well as impact of the example must be seen

as high. The high risk value needs further action. To

overcome the threat, the TTP requires user authentica-

tion before the metadata exchange is triggered. Fur-

thermore, an integrated rate limiter slows down the

number of allowed requests sent to the TTP.

All possible risks are regarded, by listing assets,

analyzing the risks of all components and the dynamic

metadata exchange itself. A wide range of possible

risks are shortly explained in the following sections.

Based on the risks, possible actor models and counter

measurements were inspected. This lead to a proto-

col, which is as secure as possible, and to a secure

designed TTP. In addition, detective and responsive

measures need to be established as well. As an ex-

ample, the local software and the TTP need to be

monitored. Further risks can be mitigated by control

by federation operators and the use of an assurance

frameworks.

4 ASSETS AND THREATS

The ﬁrst step in risk management requires the deﬁ-

nition of primary and secondary assets. While pri-

mary assets are usually the core business processes

and workﬂows of an organization, the secondary as-

sets support these processes.

4.1 Assets

In the case of dynamic metadata exchange, the TTP

enables the immediate access to online services.

Therefore, it can be seen as an enabler and innovator

for the collaboration of organizations. The secondary

assets are usually categorized as hardware and soft-

ware, information exchanged and processed by ser-

vice components. The operational risk management

focuses on the technical components of the TTP, i. e.,

the extension of the entities’ software, the TTP itself,

including the underlying network infrastructure, and

the exchanged data. As the TTP is the main compo-

nent for the automated metadata exchange, it needs to

be highly secure. Therefore, the security of the TTP,

respectively distributed TTPs, and the extensions are

discussed in this section, followed by counter mea-

sures in the following section. First the changes due

to the new approach are shown, before all components

are regarded. In order to have an overview, different

malicious actors are shown afterwards.

Federations and inter-federations currently run

metadata aggregators, which aggregate the metadata

of all members. In order to obtain and distribute meta-

data, push and pull mechanisms along with a web tool

for metadata management were implemented. Feder-

ations normally run centralized discovery services for

IDP location. By the approach described in this paper,

the following changes appear:

• TTP: instead of a standardized localization ser-

vice, the localization service is extended with a

relational database, an application programming

interface (API), a web frontend, and an orchestra-

tion service for metadata exchange.

• Federations: federation administrators manage

their federations via an administration tool, which

is part of the web service of the TTP.

• IDP/SP: IDPs and SPs use an extended software

for metadata exchange and integration, while

scripts make use of API calls.

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

230

• Communication itself: while the discovery work-

ﬂow of SAML is extended for on-demand meta-

data exchange, HTTP requests and responses are

used for API calls. If the TTPs are distributed, the

communicate between TTPs and a register for the

TTPs is added.

In principle, the approach consists of server, vir-

tual machine, web server, web application, extension

of the software, database, SAML communication, ex-

tended communication, and a network of TTPs.

4.2 Threats

A threat scenario template, as described in (Hommel

et al., 2015), can be used to point out possible events

threatening the TTP. The template characterizes an

event by actors, threat type or category, the aim, and

the likelihood as well as the impact. Based on the

changes, the threats by components, i. e., assets, are

shown, before they are explained based on the actors.

The web application of the TTP has typical

threats, like coding errors and bugs in used soft-

ware. Furthermore, the registration of a faked entity

might lead to a collection of user information or the

unauthorized usage of services. The simulation of a

higher trust can also lead to the unauthorized usage

of services, while malicious code could, e. g., read or

change the database underneath or use the web ap-

plication to spread malware. Also obtaining surrepti-

tiously higher permissions could lead to the exclusion

of entities and further misuse. As the extended local-

ization service relies on the integrity and authenticity

of the TTP, it is important that the TTP is as secure

as possible. Since the localization service let the user

trigger the metadata exchange, the availability of the

service is crucial. The underlying services and the

database also need to be secure and available.

The extension of the entities’ software enables the

automated exchange of metadata and integration into

the local conﬁguration, which can be at the same time

another threat. As the conﬁguration sets the attribute

ﬁlter, which is responsible for ﬁltering the user at-

tributes, an inaccurate conﬁguration can lead to the

disclosure of user information. On the side of SPs,

an erroneous conﬁguration can lead to the use of ser-

vices, for which users are normally not permitted.

By the automated exchange of metadata, entities

can cooperate without being member of the same fed-

eration or inter-federation. As a result, the commu-

nication between entities and TTP is a further risks,

given that a man in the middle potentially can listen

and change the communication. The authentication

and veriﬁcation of all participants is especially cru-

cial, if the TTPs are distributed (P

ohn, 2015b), since

faked TTPs might get registered. These threats can be

used to attack the TTP or participating entities by ac-

tors with different motivation, origin, knowledge, and

traceability.

5 POSSIBLE ACTORS

The different actors are explained in this sections, di-

vided into IDP/SP, user, federation, and external ac-

tors.

5.1 Entities as Actors

An IDP or SP might act as an attacker against other

entities or the TTP, if his system was compromised

or an administrator misuses his permissions, e. g., as

insider threat. One possible motivation to misuse the

permissions is to fake identities or increase the trust,

in order to use a service. While this is technically

possible, the changes are traceable. By getting higher

permissions at the TTP, other entities might be ex-

cluded or other entities might be registered. Further

manipulation, like level of trust, is possible. The ef-

forts are higher than at the ﬁrst manipulation, though

this attack should be traceable by logﬁles. By includ-

ing malicious code, the web application, scripts, the

server, or the database might be changed. Different

motivations apply for this attack, as by extracting the

data, the actor might proﬁt ﬁnancially, while it is also

possible to update entities, permissions or the trust.

The traceability for this attack is more difﬁcult, while

the ability of the actor varies from the sort of bug. At

communications, if an administrator tries to hijack a

session of another entity, information about the entity,

e. g., metadata, and trust level, as well as of the user

can be changed. The attack has to be targeted, which

means more efforts. At the same time the traceabil-

ity is less. The information can also be changed for

another entity, if social engineering is used to get the

account information. IDPs and SPs might try to ex-

change as many metadata or other data as possible to

the TTP, either to attack the TTP itself or one entity,

by this denial of service (DoS) attack. This attack

is mitigated by the DAME workﬂow, which requires

authentication before the metadata exchange is trig-

gered. Therefore, if not a bug in the implementation

let actors exchange data, the attack is traceable. Even

though the probability of an attack by an IDP or SP

is low, these attacks need to be considered. Attacks

by inside threats are the hardest to trace back and pro-

tect, while others are mitigated by the design of the

workﬂows and the TTP.

Risk Management for Dynamic Metadata Exchange via a Trusted Third Party

231

5.2 Users as Actors

Similar to IDP and SP as attackers, the likelihood of

an user to become an actor is low. It might the case, if

a user wants to harm an entity, to make use of further

services, or he wants to test his abilities or his sys-

tem was compromised. If a user exchanges as many

metadata as possible, the DoS attack can slow down a

service until it is out of service. Since the user needs

to authenticate for the metadata exchange, the trace-

ability is simple. Another possible attack is a mas-

querade attack, where a user tries to collect accounts.

This attack is not TTP-speciﬁc, as well as the social

engineering, though the impact might increase.

5.3 Federations as Actors

As the TTP has an administration tool for federations,

this interface can be misused, in order to affect an en-

tity or federation, to gain ﬁnancial advantage or, if the

federation is operator at the same time, to affect en-

tities from speciﬁc countries. Equivalent to IDP and

SP, the federation administrator can include an entity

to attack other entities, to collect user information or

to exclude a valid entity. For collecting user informa-

tion, users have to choose the service and give consent

to the data release. These attacks are basically trace-

able, if not the logﬁles are changed. If malicious code

or malicious code is used, this seems to be more dif-

ﬁcult.

When the federation is also the operator of the

TTP, further attack vectors are possible. For exam-

ple, administrators can misuse the resources, in order

to steal or change data, as described beforehand. The

infrastructure of the TTP can be attacked by an inter-

nal threat. To sum it up, internal threats are hardest

to identify, while the technical threats are taken into

account.

5.4 Externals as Actors

Attacks of externals can be targeted to the TTP, but

also to speciﬁc entities. The knowledge ranges from

script kiddies to professional hacker. While script

kiddies are comparably easy to defend, professional

hackers with money and time are a bigger threat. The

threat also depends on the entities and federations us-

ing the TTP. The localization service and the TTP

with its database is especially critical, because of the

amount of data and the exposed position. Most likely

attacks are:

• Malicious code, in order to collect data, to proto-

col inputs, to attack speciﬁc entities or all users,

to name few examples.

• Structured Query Language (SQL) injection, for

querying the database or to change data.

• Replay attacks by replaying overheard communi-

cation messages with the goal to receive further

information about the TTP and the communica-

tion.

• DoS and distributed DoS (DDoS) attacks against

the availability of the TTP or entities.

• Attacks against the user management.

• Session Hijacking and Single sign-on attacks.

Additionally to the attacks explained beforehand,

an external might try to sniff the communication be-

tween IDP, SP, and TTP, in order to get information,

e. g., to gain ﬁnancial proﬁt. The traceability of this

attack is harder. Another possible attack by an exter-

nal is the registration of a federation, which sounds

similar to well-known federations. The aim is to get

entities into the federation, receive information, and

to harm the known federation. If the actor requires a

speciﬁc certiﬁcate, audit, or payment, the attack has

also ﬁnancial consequences. The attack can be partly

traced by the database and log ﬁles, though it might be

difﬁcult to re-obtain the paid money. With distributed

TTPs, an actor might try to set up an own TTP, in or-

der to attack or exclude TTPs. The actor has ﬁrst to

implement an TTP and should understand the com-

munication between different TTPs and entities. If

the actor wants to attack TTPs directly, the TTP ﬁrst

needs to be adapted. While the effort is comparably

high, the traceability might be difﬁcult. Similar to

federations, the actor can register a TTP with a sim-

ilar name to a well-known TTP. The goal here is to

have many entities and federations registered for col-

lecting data and, in the worst case, also to gain ﬁnan-

cial beneﬁts. External actors normally have different

motivation than participants of the TTP, attaching im-

portance to these attack vectors.

6 COUNTER MEASURES

In order to either prevent or detect attacks, different

counter measures can be applied. For the components

listed in the previous section, important counter mea-

sures are the following:

• The web application of the TTP has authentication

and authorization, validation of input and output,

session management, error management, and log

ﬁles. Additionally, a secure connection to back-

ground systems as well as ﬁne grained permis-

sions are implemented. The validation of the reg-

istration is checked by certiﬁcate, email address

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

232

or a speciﬁc page on the web server, before an en-

tity can actually let metadata exchange. The local-

ization service only allows metadata exchange for

registered entities. The trust is evaluated, while all

important actions, like metadata exchanges, are

logged. Logging mechanisms are activated at the

database, where passwords are hashed and salted,

and hashes are used to validate the integrity. Fur-

thermore, all components of the TTP are moni-

tored. Federations can additionally verify entities.

• The implementation of the IDP/SP software ex-

tension has to be as secure as possible, in order to

prevent the leakage of personal information. The

administrators can conﬁgure the trust and assur-

ance as well as the degree of automation. Further-

more, users have to authenticate before metadata

can be exchanged, while, at the same time, sig-

natures, IDs for messages, and a short validation

time for asseverations are used.

• The communication is secured either by Secure

Sockets Layer (SSL) or Transport Layer Secu-

rity (TLS). Distributed TTPs are registered with

a certiﬁcate for validation with at least Domain

Name System Security Extensions (DNSSEC) or,

preferably, DNS-based Authentication of Named

Entities (DANE). Certiﬁcate transparency can be

added.

Counter measures can be distinguished between

organizational and technical measures as well as be-

tween preventive, detective, and responsive measures.

6.1 Organizational and Technical

Measures

Organizational measures regulate, who has which per-

missions for rooms and servers and how log ﬁles are

going to be evaluated. An additional security incident

response process can help to ﬁnd threats, analyze an

attack, re-establish the target stage, and to document.

In order to make use of LoA, the local LoA has to be

measured or the requirements need to be estimated.

Technical measures help to prevent and detect at-

tacks. Random numbers as session ID, tokens, and

session timeouts need to be considered during design

and implementation as well as a validation of the en-

tity by certiﬁcate, email address or a speciﬁc page on

the web server. IDPs and SPs should use either to-

kens or FIM to authenticate at the TTP. Another ex-

ample for technical measures is the authentication of

the user, before the actual metadata exchange.

6.2 Preventive, Detective, and

Responsive Measures

A different classiﬁcation divides the measures into

preventive, detective, and responsive. Preventive

measures for the dynamic metadata exchange via a

TTP include all measures, which need to be taken be-

fore a possible attack can occur. Examples are tech-

nical measures, like ﬁrewalls and salted passwords at

the TTP, as well as the usage of tokens and session

IDs during the communication. Detective measures

observe an attack, which could be done by monitor-

ing systems, such as an intrusion detection system.

Last but not least, responsive measures include secu-

rity incident response process, the automatic recon-

ﬁguration, audits, and backups. These measures and

threats were taken into account at the risk manage-

ment, helping to secure the design, extensions, and

the implementation.

7 CONCLUSIONS

The automated SAML metadata exchange enables

user-triggered exchange of metadata between IDPs

and SP across current federations’ borders. The scal-

ability of the metadata exchange in federations and

inter-federations is improved at the same time, as only

the necessary metadata is exchanged. The approach

of dynamic metadata exchange via a TTP supports

the fully automated technical setup of FIM-based au-

thentication and authorization data exchange. It there-

fore increases the automation and scalability of for-

mer manual implementation steps by administrators.

Consequently, the users can immediately use a new

service.

In order to have a secure service, which is impor-

tant for the acceptance, the risk management was ap-

plied and taken into account. The risk management

was initiated by the description and the application

of a risk management template. First, the assets and

the differences to current FIM was explained. Based

on the differences, the vulnerabilities and threats were

discussed, before possible actors against the TTP

were shown. This analysis show, that the TTP is the

biggest target in this setup and therefore has to be se-

cure. At the same time, as it is only involved during

the metadata exchange and a distributed setup can be

operated, the probability of a bottleneck is reduced.

Counter measures, divided into the different classi-

ﬁcation, demonstrated possibilities to overcome the

threats. These threats and counter measures need to

be taken into account for the improved implementa-

tion, before it can be piloted.

Risk Management for Dynamic Metadata Exchange via a Trusted Third Party

233

Further research topics relate to the level of as-

surance respectively the trust between two entities.

Though the technical trust is exchanged via the meta-

data, the quality of the entity could be assured or esti-

mated by a level of assurance and dynamic trust.

ACKNOWLEDGEMENTS

The authors wish to thank the members of the Munich

Network Management (MNM) Team for helpful com-

ments on previous versions of this paper. The MNM-

Team, directed by Prof. Dr. Dieter Kranzlm

uller

and Prof. Dr. Heinz-Gerd Hegering, is a group

of researchers at Ludwig-Maximilians-Universit

unchen, Technische Universit

at M

unchen, the Uni-

versity of the Federal Armed Forces, and the Leibniz

Supercomputing Centre of the Bavarian Academy of

Sciences and Humanities.

REFERENCES

Cantor, S., Kemp, J., Philpott, R., and Maler, E. (2005a).

Assertions and Protocols for the OASIS Security As-

sertion Markup Language (SAML) V2.0. Technical

report, OASIS.

Cantor, S., Moreh, J., Philpott, R., and Maler, E. (2005b).

Metadata for the OASIS Security Assertion Markup

Language (SAML) V2.0. Technical report, OASIS.

DFN-AAI (2015). DFN-AAI – Authentication and autho-

rization infrastructure. https://www.aai.dfn.de/en/ [ac-

cessed: 2015-11-30].

Ferdous, M. S. and Poet, R. (2013). Dynamic identity

federation using security assertion markup language

(saml). In Policies and Research in Identity Manage-

ment, pages 131–146. Springer Berlin Heidelberg.

EANT (2015). edugain membership status.

https://technical.edugain.org/status.php [accessed:

2015-11-30].

Hardt, D. (2012). The OAuth 2.0 Authorization Framework.

Rfc6749, IETF.

Hommel, W., Metzger, S., and Steinke, M. (2015). Infor-

mation Security Risk Management in Higher Educa-

tion Institutions: From Processes to Operationaliza-

tion. In Proceedings of the 21th congress of the Eu-

ropean University Information Systems Organisation,

pages 190–201. EUNIS.

InCommon (2015). About InCommon.

http://www.incommonfederation.org/about.html

[accessed: 2015-11-30].

Jiang, J., Duan, H., Lin, T., Qin, F., and Hong, Z. (2011).

A federated identity management system with central-

ized trust and uniﬁed single sign-on. In Communica-

tions and Networking in China (CHINACOM), 2011

6th International ICST Conference on, pages 785–

789. IEEE.

Odette (2009). Odette sesam speciﬁcation for building up

federated single-sign-on (sso) scenarios between com-

panies in the automotive sector – draft of 15.07.2009.

Technical report, Odette.

ohn, D. (2015a). Dynamic automated metadata exchange

– draft-pohn-dame-03. Work in Progress.

ohn, D. (2015b). Topology of Dynamic Metadata Ex-

change via a Trusted Third Party. In GI-Edition 251 -

Open Identity Summit 2015. GI.

ohn, D., Metzger, S., and Hommel, W. (2014). G

eant-

TrustBroker: Dynamic, Scalable Management of

SAML-Based Inter-federation Authentication and

Authorization Infrastructures. In ICT Systems Secu-

rity and Privacy Protection, pages 307–320. Springer

Berlin Heidelberg.

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and

Mortimore, C. (2014). OpenID Connect Core 1.0.

Technical report, OpenID Foundation.

Young, I. A. (2015). Metadata Query Protocol – draft-

young-md-query-05. Work in Progress.

Young, I. A. and Joie, C. L. (2009). Interfed-

eration and metadata exchange: Concepts and

methods. http://iay.org.uk/blog/2009/05/concepts-

v1.10.pdf [accessed: 2015-11-30].

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

234