JMX for the Shibboleth Identity...

MSE Project Thesis

JMX for the ShibbolethIdentity Provider

Halm ReusserAdvisor: Prof. Dr. Andreas Steffen

July 12, 2010

Hochschule RapperswilOberseestrasse 10

CH-8640 Rapperswil

Shibboleth is an open source software package for web single sign-on across or withinorganizational boundaries and is based on the Security Assertion Markup Language(SAML). It is well established and is an important building block of the successfulSWITCHaai identity federation.

Therefore the Shibboleth Identity Provider (IdP) is becoming one of the core servicesat the universities’ Information Technology (IT) departments. They require monitoringand management facilities in order to offer high availability, security and reliability.

Because the Authentication and Authorization Infrastructure (AAI) is the solution toauthenticating and authorizing users it is taking a major role in the field of accounting,which leads to a need of having access to usage data.

The objective of this project thesis is to collect ideas of metrics and management tasksfor the IdP, beneficial for the above-mentioned requirements. For structuring and sum-marizing those ideas, research papers and publications in the field of Federated Iden-tity Management (FIM) monitoring were consulted and helped to create a top-downoverview. The study of the literature clarified that the implementation of Java Manage-ment Extensions (JMX) is a relatively new approach and will probably have an impacton monitoring enterprise applications in the future.

As proof of concept, some of those ideas were implemented as Managed Beans (MBeans)in the Shibboleth IdP. To demonstrate the integration of the newly available status, us-age and performance information into a monitoring framework, a reference setup withthe industry standard monitoring system Nagios was accomplished.

The added JMX functionalities in the IdP provides a wide range of new possibilities,from fine grained metrics to management tasks for individual IdP components!

This project thesis demonstrates that it is archivable.

Contents

1. Introduction 61.1. Federated Identity Management, SWITCHaai and Shibboleth . . . . . . 61.2. JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Analysis 82.1. Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1. Federated Identity Management Metrics . . . . . . . . . . . . . . 82.1.2. Information Assurance Metrics . . . . . . . . . . . . . . . . . . . 82.1.3. Shibboleth Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4. Authentication Metrics . . . . . . . . . . . . . . . . . . . . . . . . 92.1.5. AMAAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.6. SLA Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2. Best Current Practices operating a SWITCHaai Identity Provider . . . . 102.3. Conclusion: Collection of Metrics and Management Tasks . . . . . . . . . 11

3. Concepts 123.1. JMX Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1. JMX Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2. MBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.3. Standard Agent Services . . . . . . . . . . . . . . . . . . . . . . . 163.1.4. Registering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2. Spring Framework JMX Support . . . . . . . . . . . . . . . . . . . . . . 183.2.1. JMX Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2. Naming Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.3. Exporting MBeans . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.4. Notification Listener . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3. Perf4J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.1. Profiled Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4. Design 234.1. Map Metrics and Management Tasks to MBeans . . . . . . . . . . . . . . 234.2. Integration Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1. Technology Decision . . . . . . . . . . . . . . . . . . . . . . . . . 24

5. Implementation 255.1. MBean Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3

5.2. Spring JMX Configuration for the Shibboleth IdP . . . . . . . . . . . . . 275.2.1. Custom Property Editors . . . . . . . . . . . . . . . . . . . . . . . 29

5.3. Shibboleth Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4. Perf4J Logback Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 305.5. MBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.1. Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . 305.5.2. Session Management . . . . . . . . . . . . . . . . . . . . . . . . . 315.5.3. Metadata Management . . . . . . . . . . . . . . . . . . . . . . . . 325.5.4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.5.5. Attribute Processing . . . . . . . . . . . . . . . . . . . . . . . . . 37

6. Integration 396.1. JMX Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2. Perf4J and Logback SMTP Appenders . . . . . . . . . . . . . . . . . . . 406.3. Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3.1. JMX Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3.2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3.3. PNP4Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7. Testing 467.1. Canoo Webtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8. Use Cases 498.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.1.1. JConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.1.2. HTTP Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508.1.3. Nagios Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.2. Managed Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.2.1. Status information . . . . . . . . . . . . . . . . . . . . . . . . . . 518.2.2. Session Management . . . . . . . . . . . . . . . . . . . . . . . . . 528.2.3. Metadata Management . . . . . . . . . . . . . . . . . . . . . . . . 548.2.4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.5. Attribute Processing Performance . . . . . . . . . . . . . . . . . . 57

9. Conclusion 609.1. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.2. Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619.3. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Glossary 62

Acronyms 63

Bibliography 63

4

A. Project proposal 67

B. Project Plan 69

C. Collected Ideas for MBeans 70

D. Reporting 71

E. Milestones 83

F. DVD 86

5

1. IntroductionThe objective of this project thesis is to collect ideas how the Shibboleth IdP could beenabled with JMX.

The first step is to collect ideas of metrics and management tasks and compare respec-tively complement them with results from research papers concerning the topic of FIMmetrics and management tasks as well as Service Level Agreement (SLA) measurements.

After an overview of potential MBeans for the Shibboleth IdP a reference implementa-tion will be undertaken for each kind of MBean and different complexities.

The last part of the project thesis provides a proof of concept which shows the possibil-ities provided by MBeans as well as a potential integration into an existing monitoringsystem like Nagios [13].

1.1. Federated Identity Management, SWITCHaai andShibboleth

Federated Identity Management (FIM) is the management and use of identity informa-tion across security domains, e.g., between individual institutions. It deals with issuessuch as interoperability, liability, security, privacy and trust.

The SWITCHaai federation [23] is a Shibboleth respectively SAML [19] based federationin Swiss higher education and research, coordinated and led by SWITCH.

Shibboleth [4] is the name of an architecture and an open source software developed byInternet2/MACE (Middleware Architecture Committee for Education). Shibboleth isbased on SAML and allows the implementation of a FIM.

1.2. JMXThe JMX defines an architecture for supporting software and network managementin the Java programming language. JMX is a unified framework to instrument thedisparate pieces of Java code in a modern IT infrastructure. Before JMX, there wasno standardized approach in the Java programming language to start, manage, monitorand stop different software components or applications [26].

6

The Java Platform Enterprise Edition (J2EE) is a complex, distributed, service-basedenterprise platform. It consists of many different kinds of resources that are dynamicallycreated, distributed, moved across nodes, redeployed and destroyed. The managementof such a platform calls for an isolation layer between the management applications andthe managed resources. The management architecture must be generic enough to allowthe management of a wide variety of different kinds of resources and components. Themanagement architecture must be able to cope with the dynamics and distribution ofthe platform and provide a management model that allows increasingly long uptimesand 24x7 service. JMX can provide all this [26].

7

2. AnalysisIn this chapter FIM metrics and management tasks are analyzed. The main objective ofthe situation analysis is to gain an overview of possible MBeans for the Shibboleth IdP.

2.1. ResearchThe first step is to collect and compare ideas with research papers concerning similarfields such FIM, Single Sign On (SSO), Lightweight Directory Access Protocol (LDAP)authentication metrics or Management Information Base (MIB) as well as similar pro-tocols like Simple Network Management Protocol (SNMP).

2.1.1. Federated Identity Management MetricsThe IEEE Computer Society published in its Security & Privacy Journal an article about“Identity management risk metrics” [29]. This article introduces the terms metrics, risk,identity management and their relation to each other. In the article various metrics areidentified, which are grouped into three categories:

Identity provider metrics Metrics like accounts, groups, authentication claims andauthorization claims.

Provisioning process metrics Metrics like requesters, approvers cycle time etc.Identity metrics Similar metrics to the Identity provider metrics but for

specific roles.

The IdP metrics are very useful for these studies and the ideas are added into thecollection. As the Shibboleth IdP is neither a provisioning system nor has support forthat, there is no gain from that aspect of the article.Furthermore, the article discusses the benefits of having well defined metrics in thecontext of risk management, service predictions and real time decision-making.

2.1.2. Information Assurance MetricsThe paper Information Assurance in Federated Identity Management [24] investigatedtwo well-known federated identity management solutions,Microsoft Passport and LibertyAlliance, attempting to identify Information Assurance requirements in FIM. One of thegoals was to measure the performance focusing on authentication. The developed metricsare mostly in the context of performance like data access time, message processing time,authentication time, SSO time etc.

8

2.1.3. Shibboleth MetricsSWITCH logs all service accesses within the SWITCHaai federation, which pass throughthe central Discovery Service. For reporting purposes, the tool WAYFalyzer exists. TheWAYFalyzer allows to aggregate accesses to IdPs or Service Providers (SPs) over arbi-trary time periods with different sampling rates. The functionalities of the WAYFalyzerare considered to be in the MBean collection.

The University of Buffalo publishes some Shibboleth statistics [20] on a monthly basis.They measure authentication requests per service as well as aggregated by domains.Those metrics are covered by the MBean collection as well.

2.1.4. Authentication MetricsUnder the term of authentication metrics a lot of research work was done in the fieldof trusted intermediate paths [30, 31]. This is not an issue within common Shibbolethfederations due to trusted Metadata.

LDAP Metrics

There are published LDAP metrics of the North Carolina State University [9]. Theymeasure indicators like binds, unbinds, successful and failed connections, searches andother typical LDAP operations. The level of granularity is on client addresses or totalcounts.

Another document of the Bucharest academy of economics focused on identity manage-ment in a university system [33]. The outcome concerning metrics is divided into twoaspects of the system. The first is very similar to the above-mentioned LDAP metricsi.e., measure typical LDAP operations. The second type of measurements is related withthe performance of SSO request processing, but the implementation is on a very generallevel like Hypertext Transfer Protocol (HTTP) server process usage, connections, servletresponse time as well as load and number of current session.

2.1.5. AMAAISThe collected ideas were sent for a review purpose to the AMAAIS project team [1],whose primary objective is to enable accounting and monitoring functionality for aShibboleth-based AAI. The AMAAIS project team reviewed the metrics assessed, ap-proved them and found no critical missing metrics.

2.1.6. SLA MeasurementsSLA metrics are used to measure performance characteristics of the service objects.They are retrieved directly from the managed resource, middleware or instrumentedapplications.

9

Several studies about SLA metrics were consulted, e.g., IP-Oriented Operations andManagement [27], A Categorization Scheme for SLA Metrics [28] or SLA managementin federated environments [25]. Presented metrics (MIB variables) which are of inter-est for this work are categorized as reliability, performance, response time, throughput,utilization, system uptime, outage period, availability etc.A distinction between direct or aggregated higher-level composite metrics is made.

2.2. Best Current Practices operating a SWITCHaaiIdentity Provider

The SWITCHaai team — together with the SWITCHaai community — published apaper called BEST CURRENT PRACTICES for operating a SWITCHaai IdentityProvider [32]. Thanks to those requirements and suggestions, possible ideas for MBeanscould be extracted.

10

2.3. Conclusion: Collection of Metrics and ManagementTasks

While studying the research papers and other resources, many generic metrics (MBeanmeasurements) as well as specific ones like FIM metrics were discovered. Almost all met-rics and measurements were based on SNMP and MIB based systems. Concrete JMXimplementation have not been found. It seems that this relatively new technology andapproach — to hook directly into Java applications and monitor and manage individualcomponents — will affect service management in the future.

Another input adopted from the research papers was the whole structure and catego-rization of the metrics and management tasks.

The result of the research paper analysis, SWITCHaai documents and experiences as wellas the discussion with several stakeholders is summarized as a mind map in appendix C.The essence is that most of the MBeans can be categorized as follows:

Accounting Typical countable facts, such as logins, profile usages, authenticationsetc.

Reliability MBeans, which support reliability measures like uptime and service sta-tus information.

Performance Typical time measures for various operations and processes like Incom-ing/Outgoing message processing, Authentication and Attribute resolv-ing/filtering.

Security Security related metrics e.g., certificate validity or failed authentications.Management MBeans supporting management and operation tasks such as reloading

configuration files, refreshing metadata and session management.

11

3. ConceptsThe chapter “Concepts” introduces the used concepts, technologies, frameworks andlibraries such as JMX, Spring [22] and Perf4J [16].

3.1. JMX ConceptsIn this section the main architecture and concepts of the JMX are explained.

3.1.1. JMX ArchitectureFigure 3.1 shows the JMX architecture. It consists of the following levels:

Probe level The probe level contains the probes (called MBeans) in-strumenting the resources. Also called the instrumenta-tion level.

Agent level The agent level, or MBeanServer, is the core of JMX. Itis an intermediary between the MBean and the applica-tions.

Remote management level The remote management level enables remote applica-tions to access the MBeanServer through connectors andadaptors.A connector provides full remote access to the MBeanServerApplication Programming Interface (API) using variouscommunication frameworks as Remote Method Invoca-tion (RMI) etc., while an adaptor adapts the API toanother protocol (SNMP, . . . ) or to a web-based userinterface.

12

Figure 3.1.: JMX Architecture [6]

Applications can be generic consoles such as JConsole or domain-specific (monitoring)applications. External applications can interact with the MBeans through the use ofJMX connectors and protocol adapters. Connectors are used to connect an agent witha remote JMX-enabled management application. This form of communication involvesa connector in the JMX agent and a connector client in the management application.

3.1.2. MBeansThe JMX specification defines different types of MBeans:

Standard MBeans Implement a business interface (e.g., HumanMBean) containing set-ters and getters for the attributes and the operations (i.e., meth-ods). See Figure 3.2.

13

HumanMBeansetName(name:String)getName():StringsetAge(age:int)getAge():intsayHello()

Humanname:Stringage:intsetName(name:String)getName():StringsetAge(age:int)getAge():intsayHello()

Figure 3.2.: Standard MBean

The advantages of Standard MBeans are that those are simpleto understand and implement. The disadvantage is that a newinterface has to be specified and implemented which might breakexisting APIs.

Dynamic MBeans Implement the javax.management.DynamicMBean interface whichprovides a way to list the attributes and operations, and to get andset the attribute values.

DynamicMBeangetMBeanInfo():MBeanInfogetAttribute(attribute:String):ObjectgetAttributes(attributes:String[]):AttributeListsetAttribute(Attribute attribute)setAttributes(AttributeList attributes):AttributeListObject invoke(String actionName, Object[] params, String[] signature):Object

Figure 3.3.: Dynamic MBean

Using the DynamicMBean interface for defining MBeans all attributes,operations and notifications could be defined dynamically i.e., atrun-time.The methods described in the interface (see Figure 3.3) are genericand detyped. Therefore some extra discipline is required in orderto implement Dynamic MBeans. The generic definition of the Dy-namic MBean interface provides increased flexibility but should behandled with care.

Model MBeans Are an extension of the Dynamic MBean. They provide a generic,configurable template for the developer to easily instrument a re-

14

source for management. The Spring framework JMX support makesuse of Model MBeans.

Standard and Dynamic MBeans are the two basic types of MBeans mandatory imple-mented by all compliant JMX implementations.

There are other variants like Open MBean and MXBean which are not considered fur-ther.

MBean Definitions

Each MBean has some characteristics. The most important ones are:Class characteristics An MBean must be a public, non-abstract class. An MBean

must have at least one public constructor. An MBean mustimplement its own corresponding MBean (Standard MBean) orthe DynamicMBean interface.

Attributes Management attributes are named characteristics of an MBean.There are three kinds of attributes, read-only, write-only andread-write attributes. Attributes can be of any valid Java type.

Operations Management operations include all methods declared within theMBean. Management operations can have return values. Thearguments as well as the return value can be of any valid Javatype. An operation may throw any type of exceptions.

Notifications The JMX notifications are based on the Java event mechanismand used for events and state changes.An MBean broadcasting management events must implementthe NotificationBroadcaster interface.A NotificationListener can subscribe and unsubscribe to aNotificationBroadcaster.It is possible using the NotificationFilter to only get a spe-cific type of Notification.Defined notification types are AttributeChangeNotificationor ThresholdExceededNotification for instance. Custom im-plementations are possible.

Object name Represents the object name of an MBean, or a pattern that canmatch the names of several MBeans [7]. It is used for registeringand lookup MBeans in the registry. An object name consists oftwo parts, the domain and the key properties. The domain is astring of characters not including the character colon (:). Thekey properties are an unordered set of keys and associated values.Example: org.example.mbeans:type=Monitor,name=MyMBean.

The implementation of attributes, management operations and notifications as well asthe determination of it is different in Standard respectively Dynamic MBeans.

15

3.1.3. Standard Agent ServicesThe Standard agent services MBeans are just an architectural distinction to resourceMBeans. On the code implementation level they are considered the same. Those stan-dard agent services are implemented by all compliant JMX implementations.

Timer service The timer service is based on the JMX notification mechanism andcan be used to schedule notifications to occur at a given date and timeor at defined intervals. The JMX timer service is a similar servicelike the cron service on Unix systems.

Monitor service The monitor service can be used to monitor the attributes of managedresources. Monitors can be utilized to provide notifications aboutattribute changes, threshold overstepping etc. The monitor serviceis examined carefully in section 3.1.3.

M-Let service The M-Let service is a mechanism to dynamically load new Javaclasses to the MBean server. In addition, the M-Let service allowsthe configuration of the application to be moved onto a remote server,thus allowing a centralized location of the configuration of an appli-cation.

Relation service The relation service can be used for defining relations between MBeans.The relation service maintains consistency of the relations.

Figure 3.4.: Standard Agent Services

16

Monitor Service

For this work the monitor service is of special interest. There are three types of monitors:

Counter monitor The counter monitor can be used to track attribute values that actlike counters. This means that the monitored value is integer typed,always greater than or equal to zero and only incremented.

Gauge monitor The gauge monitor can be used to monitor attribute values thatare either integer or floating point types and arbitrarily increase ordecrease.

String monitor The string monitor can be used to monitor attributes of the Stringtype and notify the interested listeners whether the observed at-tribute value matches an expected string value or differs from it.

The counter monitor uses a threshold value to determine when a notification should besent to the interested listeners. When the observed attribute’s value increases to matchor exceed the threshold a notification is sent. The offset is added to the threshold asmany times as it is necessary for the threshold value to become greater than the currentobserved attribute value. However, only one notification is ever sent, no matter howmany times the offset must be added to the threshold value [26]. The behavior of thecounter monitor is shown in the Figure 3.5.

For counters which roll over at a given point it is necessary to set a modulus value.

Figure 3.5.: CounterMonitor Notifications

17

3.1.4. RegisteringListing 3.1 illustrates how to retrieve the platform’s MBeanServer.c l a s s j a v a . l a n g . management . ManagementFactory {

s t a t i c MBeanServer getP lat fo rmMBeanServer ( ) { . . . }}

Listing 3.1: Retrieving the MBeanServer of the Platform

After the MBeanServer is available it can be used to register an MBean implementationusing a given ObjectName. See Listing 3.2.MBeanServer s e r v e r = ManagementFactory . getP lat fo rmMBeanServer ( ) ;ObjectName name = new ObjectName ( "org. example .jmx:name=Foo" ) ;FooMBean foo = new Foo ( ) ;s e r v e r . r eg i s t e rMBean ( foo , name ) ;

Listing 3.2: Register an MBean

3.2. Spring Framework JMX SupportThe Spring framework [22] is an open source application framework for the Java platform.

The JMX support in Spring provides the features to easily and transparently integratea Spring application into a JMX infrastructure.

The following core features of Spring’s JMX support are used:

• The automatic registration of any Spring bean as a JMX MBean.

• Annotation driven controlling of the MBean management interfaces.

3.2.1. JMX AnnotationsAn annotation, in the Java programming language, is a special form of syntactic meta-data that can be added to Java source code. Classes, methods, variables, parameters andpackages may be annotated. Unlike Javadoc tags, Java annotations can be reflective inthat they can be embedded in class files generated by the compiler and may be retainedby the Java Virtual Machine (JVM) to be made retrievable at run-time.

To enable the use of annotations for the management interface definition, Spring providesa set of annotations that mirror the commons attribute classes and an implementationof the JmxAttributeSource strategy interface, the AnnotationsJmxAttributeSourceclass, that allows the MBeanInfoAssembler to read them.Listing 3.3 shows a bean where the management interface is defined by the presence ofannotation types.

18

@ManagedResource ( objectName="org. example :type=Human ,name=Me" )@ManagedNot i f i ca t i on ( name=" AgeChangeNotification " , n o t i f i c a t i o n T y p e s ={" AgeChange " })pub l i c c l a s s Human implements N o t i f i c a t i o n P u b l i s h e r A w a r e {

p r i v a t e S t r i n g name ;p r i v a t e i n t age ;p r i v a t e N o t i f i c a t i o n P u b l i s h e r p u b l i s h e r ;

pub l i c Human( S t r i n g name , i n t age ) {t h i s . name = name ;t h i s . age = age ;

}

@ManagedAttr ibute ( d e s c r i p t i o n="The name attribute " )pub l i c S t r i n g getName ( ) {

r e t u r n name ;}

@ManagedAttr ibute ( d e s c r i p t i o n="The age attribute " )pub l i c i n t getAge ( ) {

r e t u r n age ;}

@ManagedAttr ibute ( d e s c r i p t i o n="The age attribute " )pub l i c vo id setAge ( i n t age ) {

t h i s . age = age ;p u b l i s h e r . s e n d N o t i f i c a t i o n (

new N o t i f i c a t i o n ( " AgeChange " , t h i s , 0 , s a y H e l l o ( ) ) ) ;}

@ManagedOperation ( d e s c r i p t i o n=" Returns the humans name and age" )pub l i c S t r i n g s a y H e l l o ( ) {

r e t u r n "I’m " + name + ", " + age + " years old" ;}

@ManagedOperation ( d e s c r i p t i o n=" Introduce itself to another " )@ManagedOperat ionParameter ( name = "name" , d e s c r i p t i o n = "The name of the other " )pub l i c S t r i n g i n t r o d u c e Y o u r s e l f ( S t r i n g name ) {

r e t u r n " Hello " + name + "! " + s a y H e l l o ( ) ;}

pub l i c vo id s e t N o t i f i c a t i o n P u b l i s h e r ( N o t i f i c a t i o n P u b l i s h e r p u b l i s h e r ) {t h i s . p u b l i s h e r = p u b l i s h e r ;

}

}

Listing 3.3: Spring JMX Annotations

3.2.2. Naming StrategySpring supports different naming strategies or presents other ways of controlling objectnames. Following strategies are used:

Key naming The MBean is explicitly declared as a property of the MBeanExporter.The key of the map is used as the ObjectName. See Listing 3.4 foran example.

Metadata naming Uses the objectName property of the ManagedResource attributeon each bean to create the ObjectName. See Listing 3.3 for an

19

example.Self naming The MBean implements the SelfNaming interface, which allows to

provide the ObjectName.

3.2.3. Exporting MBeans

<bean i d=" exporter " c l a s s="org. springframework .jmx. export . MBeanExporter ">

<e n t r y key="org. example:name =some - component "va lue−r e f="some - component "/>

. . .

</ bean>

Listing 3.4: MBeanExporter

MBeans can be automatically detected by the MBeanExporter by setting the autodetectproperty to true.The beans property tells the MBeanExporter explicitly which of the beans to registerusing the KeyNamingStrategy.

3.2.4. Notification ListenerHow to publish notifications using the NotificationPublisherAware interface and@ManagedNotification annotation is shown in Listing 3.3.For receiving notifications a class implementing the NotificationListener interface isneeded. A simple LoggingNotificationListener might look like in Listing 3.5.pub l i c c l a s s L o g g i n g N o t i f i c a t i o n L i s t e n e r implements N o t i f i c a t i o n L i s t e n e r ,

N o t i f i c a t i o n F i l t e r {

p r i v a t e f i n a l Logger l o g = Logge rFac to r y . ge tLogge r ( g e t C l a s s ( ) ) ;

pub l i c vo id h a n d l e N o t i f i c a t i o n ( N o t i f i c a t i o n n o t i f i c a t i o n , Object handback ) {l o g . e r r o r ( "\n*** Notification ***\n{}\n*** Notification ***" , n o t i f i c a t i o n ) ;

}

pub l i c boo lean i s N o t i f i c a t i o n E n a b l e d ( N o t i f i c a t i o n n o t i f i c a t i o n ) {r e t u r n t rue ;

}

}

Listing 3.5: LoggingNotificationListener

The MBeanExporter allows to define a NotificationListener mapping.The Listing 3.6 defines that every published notification is sent to theLoggingNotificationListener.<bean i d=" exporter " c l a s s="org. springframework .jmx. export . MBeanExporter ">

. . .

20

<map><e n t r y key="*">

<bean c l a s s=" mseproject .jmx. listener . LoggingNotificationListener "/></ e n t r y>

</map>

</ bean>

Listing 3.6: NotificationListener Mapping

3.3. Perf4JPerf4J [16] is a set of utilities for calculating and displaying performance statistics forJava code. It is integrated with the most common logging frameworks.

It provides aggregated performance statistics like mean, minimum, maximum, standarddeviation and transactions per second over a set time span.The main reason to use the Perf4j library is the ability to expose those performancestatistics as JMX attributes and to send notifications when statistics exceed specifiedthresholds.

3.3.1. Profiled AnnotationPerf4J provides a @Profiled annotation and a set of custom aspects that allow unob-trusive timing statements when coupled with an AOP framework such as Spring AOP.

Listing 3.7 demonstrates the usage of the @Profiled annotation to profile a methodcall. The logger parameter indicates to which appender the performance statistics aresent.

@ P r o f i l e d ( tag=" execution " , l o g g e r=" logger . service " )pub l i c vo id s e r v i c e ( l ong m i l l i s ) {

l o g g e r . i n f o ( "Run service for {} millis " , m i l l i s ) ;t r y {

Thread . s l e e p ( m i l l i s ) ;} catch ( I n t e r r u p t e d E x c e p t i o n e ) {}

}

Listing 3.7: Profiled Annotation

Listing 3.8 shows the logging configuration with the specific appenders.<appender name=" service . statistics . console "

c l a s s="ch.qos. logback .core. ConsoleAppender "/>

<appender name=" service . statistics "c l a s s=" AsyncCoalescingStatisticsAppender ">

<param name=" TimeSlice " v a l u e=" 10000 " /><appender−r e f r e f=" service . statistics . console " />

</appender>

<l o g g e r name=" logger . service " a d d i t i v i t y=" false ">< l e v e l v a l u e="INFO" />

21

<appender−r e f r e f=" service . statistics " /></l o g g e r >

Listing 3.8: Perf4J Configuration

The AsyncCoalescingStatisticsAppender groups performance log messages intoGroupedTimingStatistics messages which it sends to the console:

Performance Statistics 2010-06-04 18:25:40 - 2010-06-04 18:25:50Tag Avg(ms) Min Max Std Dev Countexecution 3403.0 3403 3403 0.0 1



Instead of output those performance statistics, Perf4J provides other appenders suchas the JmxAttributeStatisticsAppender which exposes the performance statistics at-tributes in an MBean. The GraphingStatisticsAppender provides generated perfor-mance charts using the Google Chart API [3].

22

4. DesignThis chapter discusses the aspects of how to map the collected metrics and managementtasks to MBeans (according to Section 2.3) as well as the thoughts which technologies(frameworks, libraries, . . . ) to use.

The implementation level design of each individual MBean is described in Chapter 5.

4.1. Map Metrics and Management Tasks to MBeansIt is important to order and classify the collected ideas into specific type of MBeanswhich have structural similarities.

MetricsIn the field of metrics there are the types information, frequency1 and time measure withthe characteristics listed in Table 4.1.

Informationarbitrary readable attributeString- or CounterMonitor with adequatethresholds.

Frequencycounter attribute (integer)CounterMonitor in DifferenceMode withadequate granularity and thresholds.

Time measurecounter attribute (integer) of process callscounter attribute (long) of process timesLast info (count, start, end, duration).

Table 4.1.: Mapped Type of Metrics to MBeans

1Events per time unit

23

Management TasksIn the field of management tasks there are the types configuration and managementtasks with the characteristics listed in Table 4.2.

Configuration arbitrary writable attribute.

Management tasks arbitrary method calls witharbitrary return type and argument type(s).

Table 4.2.: Mapped Type of Management Tasks to MBeans

4.2. Integration DesignThe design of the MBean integration into the Shibboleth IdP respects SUN’s JMX bestpractices [8].

4.2.1. Technology DecisionDue to the fact that the Shibboleth IdP uses the Spring framework, the simplest inte-gration approach is to make use of the Spring JMX support. After a feasibility study itbecomes clear that it should be feasible almost without any drawbacks.

Perf4J is a very convenient profiling library. The supplementary support for exposingperformance data as JMX attributes in MBeans justifies its choice.

24

5. ImplementationAfter collecting some ideas, studying available concepts and mapping the ideas to aspecific type of MBean, the objective is to provide a reference implementation fulfillingthe following requirements. Pick at least one:

• From every context (accounting, operation, . . . )

• From every type of metrics and management tasks (readable/writable attributes,counter, operations, time measures)

• From every complexity type

Table 5.1 provides the proposed specification for a set of MBeans which are implemented.The rest of this chapter covers the implementation approach of these MBeans.

25

5.1.

MBeanSp

ecificatio

n

Con

text

Feat

ures

Com

plex

ity

Ope

ratio

nsSessions

coun

tactiv

esessions

getlistof

userswith

session

destroysessionforuser

destroyalls

essio

ns

read

able

attribute

read

able

attribute

operationwith

1argu

ment

operation

Medium

2

Ope

ratio

nsMetad

ata

Expo

seforeach

MDPr

oviderID

:reload

metad

ata

getlast

reload

timestamp

set/getmaintainexpiredmetad

ata

send

notifi

catio

nin

case

ofchan

ge

requ

iresDyn

amicMBe

anop

eration

operationwith

return

value

read

-and

writ

able

attribute

notifi

catio

n

Com

plex

3

Reliability

IdP

uptim

eIdP

status

getup

time

getsim

plestatus

(OK,N

OK)

read

able

attribute

read

able

attribute

with

Strin

gmon

itor(alerts)

Simple

1

Accou

nting

Authentications

Expo

seforeach

loginha

ndler:

coun

tof

authentic

ation

requ

iresDyn

amicMBe

ancoun

termon

itor

Medium

2

Securit

yFa

iled

au-

thentic

ations

Expo

seforeach

loginha

ndler:

coun

tof

failedau

thentic

ations

requ

iresDyn

amicMBe

ancoun

termon

itorwith

threshold

notifi

catio

ns(alerts)

Simple

1

Perfo

rman

ceAttrib

ute

processin

gprocessin

gtim

eforattributeresolving

&filterin

gtim

emeasure

with

mon

itor

Com

plex

3

Table5.1.:M

Bean

Specificatio

n

26

5.2. Spring JMX Configuration for the Shibboleth IdPThe Spring JMX beans and configuration items are defined for clarity purposes in aseparate file internal-jmx.xml, which is included by the IdPs main application contextinternal.xml. See Listing 5.1.<beans>

<!−− Other S h i b b o l e t h IdP Beans D e c l a r a t i o n s −−>

<impor t r e s o u r c e="internal -jmx.xml"/></ beans>

Listing 5.1: internal.xml

Listing 5.2 exposes the Spring JMX setup configuration. It includes:

• The Aspect Orientated Programming (AOP) configuration needed for the Perf4J@Profiled annotation (Line 11).

• The custom property editor configuration. See Section 5.2.1, (Line 15).

• The MBeanExporter setup (Line 33), the assembling (Line 72) and naming (Line 77)configuration as well as the explicit registration of some MBeans (Line 40).

• The NotificationListener mapping. See Section 3.2.4, (Line 58).

• The setup of an RMI registry (Line 83).

• The configuration of a sever connector over RMI (Line 89).

• The setup of an Hypertext Markup Language (HTML) adaptor. See Section 8.1.2,(Line 98).

• The includes for the JMX monitors. See Section 6.1, (Line 102).

<?xml v e r s i o n="1.0" encod ing="UTF -8"?>

<beans xmlns=" http: // www. springframework .org/ schema / beans "x m l n s : x s i=" http: // www.w3.org /2001/ XMLSchema - instance "

5 xmlns :aop=" http: // www. springframework .org/ schema /aop"x s i : s c h e m a L o c a t i o n=" http: // www. springframework .org/ schema / beans

http: // www. springframework .org/ schema / beans /spring - beans .xsdhttp: // www. springframework .org/ schema /aophttp: // www. springframework .org/ schema /aop/spring -aop.xsd">

10<!−− AOP C o n f i g u r a t i o n −−><a o p : a s p e c t j−autop roxy proxy−t a r g e t−c l a s s="true"/><bean i d=" timingAspect " c l a s s="org. perf4j . slf4j .aop. TimingAspect "/>

15 <!−− Custom P r o p e r t y E d i t o r C o n f i g u r a t i o n −−><bean name=" customEditorConfigurer "

c l a s s="org. springframework . beans . factory . config . CustomEditorConfigurer ">

<map>20 <e n t r y key="java.lang. Number ">

<bean c l a s s="org. springframework . beans . propertyeditors . CustomNumberEditor ">

27

<c o n s t r u c t o r−arg v a l u e="java.lang. Integer "/><c o n s t r u c t o r−arg v a l u e=" false "/>

</ bean>25 </ e n t r y>

<e n t r y key=" javax . management . ObjectName "><bean c l a s s=" mseproject . spring . editors . ObjectNamePropertyEditor "/>

</ e n t r y></map>

30 </ bean>

<!−− MBean E x p o r t e r C o n f i g u r a t i o n −−><bean i d=" exporter " c l a s s="org. springframework .jmx. export . MBeanExporter ">

35

40 <!−− MBean R e g i s t r a t i o n −−>

<map><e n t r y key=" mseproject:type = Information ,name= StatusMonitor "

va lue−r e f=" mseproject . monitor . status "/>45 <e n t r y key=" mseproject:type = Authentication ,name= UsernamePasswordSPMMonitor "

va lue−r e f=" mseproject . monitor . authentication . usernamepassword .spm"/><e n t r y key=" mseproject:type = Authentication ,name= UsernamePasswordFPMMonitor "

va lue−r e f=" mseproject . monitor . authentication . usernamepassword .fpm"/><e n t r y key=" mseproject:type = Authentication ,name= PreviousSessionSPMMonitor "

50 va lue−r e f=" mseproject . monitor . authentication . previoussession .spm"/><e n t r y key=" mseproject:type = Authentication ,name= PreviousSessionFPMMonitor "

va lue−r e f=" mseproject . monitor . authentication . previoussession .fpm"/><e n t r y key=" mseproject:type =Adaptor ,name=HTML"

va lue−r e f=" mseproject . HtmlAdaptor "/>55 </map>



<!−− N o t i f i c a t i o n L i s t e n e r Mapping −−>

60 <map><e n t r y key="*">

<bean c l a s s=" mseproject .jmx. listener . LoggingNotificationListener "/></ e n t r y></map>

65 </ bean>

<!−− MBean Assembl ing and Naming C o n f i g u r a t i o n −−><bean i d=" jmxAttributeSource "

70 c l a s s="org. springframework .jmx. export . annotation . AnnotationJmxAttributeSource "/>

<bean i d=" assembler "c l a s s="org. springframework .jmx. export . assembler . MetadataMBeanInfoAssembler ">

75 </ bean>

<bean i d=" namingStrategy "c l a s s="org. springframework .jmx. export . naming . MetadataNamingStrategy ">

80 

</ bean>

<!−− RMI R e g i s t r y −−><bean i d=" registry "

85 c l a s s="org. springframework . remoting .rmi. RmiRegistryFactoryBean ">

</ bean>

28

<!−− S e r v e r Connector −−>90 <bean i d=" serverConnector "

c l a s s="org. springframework .jmx. support . ConnectorServerFactoryBean "></ bean>

<!−− HTML Adaptor ( h t t p : // l o c a l h o s t : 8 0 8 2 ) −−><bean i d=" mseproject . HtmlAdaptor "

100 c l a s s="com.sun.jdmk.comm. HtmlAdaptorServer " i n i t −method=" start " />

<!−− JMX Monitor C o n f i g u r a t i o n −−><impor t r e s o u r c e="internal -jmx - monitor .xml"/>

105 </ beans>

Listing 5.2: internal-jmx.xml

5.2.1. Custom Property EditorsSpring provides a set of property editors which are used to convert from String valuesto object values such as Integer, Date etc. This is a very convenient feature. Sometypes are not enabled by default. In this project a property editor Number is required.The Spring framework provides a CustomNumberEditor which has to be configured ex-plicitly. See Listing 5.2.

If conversions are needed the framework doesn’t provide, one has to implement an editorby extending the PropertyEditorSupport class. Because the type ObjectName is oftenused by the JMX an implementation was necessary.The source of the ObjectNamePropertyEditor can be found on the DVD. See Ap-pendix F.

5.3. Shibboleth ModulesThe Shibboleth IdP consists of three main software components. Table 5.2 indicateswhich software versions are branched.

29

Component Description Branchedversion

Shibboleth Identity Provider The Shibboleth Identity Provider is usedby an organization to securely assert in-formation, via SAML, about their users.

2.2.0 (r2933)

Shibboleth Common Library The Shibboleth Common Library providesservices/infrastructure that is commonbetween Identity and Service providers.

1.2.0 (r900)

OpenSAML-J The OpenSAML-J library provides toolsto support developers working with theSecurity Assertion Markup Language(SAML).

2.4.0 (r1467)

Table 5.2.: Shibboleth Component Versions

5.4. Perf4J Logback ExtensionsThe Perf4J library uses existing logging frameworks for publishing performance data toseveral appenders. See Section 3.3.

Unfortunately the Perf4J library supports only the “old” logging frameworks like Log4J,JUL and Apache Commons. The IdP uses SLF4J [21] and Logback [10] as logging frame-work.

The design of Perf4J allows an easy integration of SLF4J implementations but thesupport for Logback is non-yet released. Although it is on the roadmap I decided toimplement the Logback support in the meantime by myself.

The classes AsyncCoalescingStatisticsAppender, GraphingStatisticsAppender andJmxAttributeStatisticsAppender of Perf4J was Logback-enabled and can be found onthe DVD. See Appendix F.

5.5. MBeansThis section contains all implemented MBeans. The most important design ideas andcode level changes are described.

5.5.1. Status InformationSo far the IdP provides a StatusServlet which provides some status information.Listing 5.3 illustrates how this component is JMX enabled by the usage of the@ManagedAttribute annotations.

30

@ManagedResource ( objectName=" mseproject :type= Information ,name= Status " ,d e s c r i p t i o n=" Status information of the Identity Provider " )

pub l i c c l a s s S t a t u s S e r v l e t extends H t t p S e r v l e t {. . .p r i v a t e s t a t i c f i n a l s ho r t OK = 0 ;p r i v a t e s t a t i c f i n a l s ho r t WARNING = 1 ;p r i v a t e s t a t i c f i n a l s ho r t CRITICAL = 2 ;. . .pub l i c vo id i n i t ( S e r v l e t C o n f i g c o n f i g ) throws S e r v l e t E x c e p t i o n {

. . .// JMX s e l f r e g i s t r a t i o nWebApp l i ca t ionContex t c o n t e x t =

W e b A p p l i c a t i o n C o n t e x t U t i l s . g e tWebApp l i ca t i onContex t ( g e t S e r v l e t C o n t e x t ( ) ) ;MBeanExporter e x p o r t e r = ( MBeanExporter ) c o n t e x t . getBean ( " exporter " ) ;e x p o r t e r . setEnsureUniqueRunt imeObjectNames ( f a l s e ) ;e x p o r t e r . r e g i s t e r M a n a g e d R e s o u r c e ( t h i s ) ;

}. . .

@ManagedAttr ibute ( d e s c r i p t i o n=" Start date/time of the Identity Provider " )pub l i c Date g e t S t a r t t i m e ( ) {

r e t u r n s t a r tT ime . toDate ( ) ;}

@ManagedAttr ibute ( d e s c r i p t i o n=" Uptime of the Identity Provider in seconds " )pub l i c long getUpt ime ( ) {

DateTime now = new DateTime ( ISOChronology . get InstanceUTC ( ) ) ;r e t u r n now . minus ( s t a r tT ime . g e t M i l l i s ( ) ) . g e t M i l l i s ( ) / 1000 ;

}

@ManagedAttr ibute ( d e s c r i p t i o n="The status code of the Identity Provider " )pub l i c sho r t g e t S t a t u s c o d e ( ) {

t r y {a t t r i b u t e R e s o l v e r . v a l i d a t e ( ) ;r e t u r n OK;

} catch ( A t t r i b u t e R e s o l u t i o n E x c e p t i o n e ) {r e t u r n CRITICAL ;

}}

@ManagedAttr ibute ( d e s c r i p t i o n="The status code of the Identity Provider " )pub l i c S t r i n g g e t S t a t u s ( ) {

sw i tch ( g e t S t a t u s c o d e ( ) ) {case OK: r e t u r n "OK" ;case WARNING: r e t u r n " WARNING " ;case CRITICAL : r e t u r n " CRITICAL " ;

}r e t u r n " UNKNOWN " ;

}

@ManagedAttr ibute ( d e s c r i p t i o n=" Version of the Identity Provider " )pub l i c S t r i n g g e t V e r s i o n ( ) {

r e t u r n V e r s i o n . c l a s s . getPackage ( ) . g e t I m p l e m e n t a t i o n V e r s i o n ( ) ;}

}

Listing 5.3: StatusMBean

5.5.2. Session ManagementListing 5.4 illustrates the extension of the SessionManagerImpl component to providethe required JMX functionalities.

31

The main addition and changes are the introduction of a session counter and thegetSessions() and destroySessions() operations.@ManagedResource ( objectName=" mseproject :type= Management ,name= Session " ,

d e s c r i p t i o n=" Session management of the Identity Provider " )pub l i c c l a s s Sess ionManager Imp l implements Sess ionManager<Ses s i on >, . . . {

. . .p r i v a t e i n t s e s s i o n C o u n t = 0 ;. . .pub l i c S e s s i o n c r e a t e S e s s i o n ( ) {

. . .s e s s i o n C o u n t++;. . .

}

. . .

@ManagedOperation ( d e s c r i p t i o n=" Destroy a session " )@ManagedOperat ionParameter ( name=" sessionID " , d e s c r i p t i o n="The sessionID " )pub l i c vo id d e s t r o y S e s s i o n ( S t r i n g s e s s i o n I D ) {

// a l r e a d y implemented method}

@ManagedAttr ibute ( d e s c r i p t i o n=" Current sessions " )pub l i c Map<S t r i n g , S t r i n g > g e t S e s s i o n s ( ) {

// a d d i t i o n a l method}

@ManagedAttr ibute ( d e s c r i p t i o n=" Count of current sessions " )pub l i c i n t getCount ( ) {

r e t u r n s e s s i o n C o u n t ;}

@ManagedOperation ( d e s c r i p t i o n=" Destroy current sessions " )pub l i c i n t d e s t r o y S e s s i o n s ( ) {

i n t count = s e s s i o n C o u n t ;f o r ( S t r i n g s e s s i o n I D : g e t S e s s i o n s ( ) . keySet ( ) )

d e s t r o y S e s s i o n ( s e s s i o n I D ) ;r e t u r n count ;

}}

Listing 5.4: SessionMBean

5.5.3. Metadata ManagementFor implementing the metadata management MBean,the ResourceBackedMetadataProvider was annotated as listed in Listing 5.5.

Due to @Managed* annotations are not @Inherited (as in Spring 3.x) some methodshave to be overridden.@ManagedResource@ManagedNot i f i ca t i on ( name=" MetadataChangeNotification " ,

n o t i f i c a t i o n T y p e s ={" MetadataChange " } ,d e s c r i p t i o n=" Sends a notification if metadata were changed " )

pub l i c c l a s s ResourceBackedMetadataProv ide r extends A b s t r a c t R e l o a d i n g M e t a d a t a P r o v i d e rimplements N o t i f i c a t i o n P u b l i s h e r A w a r e {

32

. . .

@ManagedAttr ibute ( d e s c r i p t i o n="Last refresh of the metadata " )pub l i c Date g e t L a s t R e f r e s h D a t e ( ) {

r e t u r n super . g e t L a s t R e f r e s h ( ) . toDate ( ) ;}

@ManagedAttr ibute ( d e s c r i p t i o n="Last update of the metadata " )pub l i c Date getLastUpdateDate ( ) {

r e t u r n super . ge tLas tUpdate ( ) . toDate ( ) ;}

@ManagedAttr ibute ( d e s c r i p t i o n=" Expiration date of the metadata " )pub l i c Date g e t E x p i r a t i o n D a t e ( ) {

r e t u r n super . g e t E x p i r a t i o n T i m e ( ) . toDate ( ) ;}

@ManagedOperation ( d e s c r i p t i o n=" Refresh the metadata " )pub l i c vo id r e f r e s h ( ) throws M et ad a t a Pr ov i d e r Ex c ep t i on {

super . r e f r e s h ( ) ;}

@ManagedAttr ibute ( d e s c r i p t i o n=" Require valid metadata " )pub l i c boo lean g e t R e q u i r e V a l i d M e t a d a t a ( ) {

r e t u r n super . r e q u i r e V a l i d M e t a d a t a ( ) ;}

@ManagedAttr ibute ( d e s c r i p t i o n=" Require valid metadata " )pub l i c vo id s e t R e q u i r e V a l i d M e t a d a t a ( boolean r e q u i r e ) {

super . s e t R e q u i r e V a l i d M e t a d a t a ( r e q u i r e ) ;}

pub l i c vo id emitChangeEvent ( ) {super . emitChangeEvent ( ) ;i f ( n o t i f i c a t i o n P u b l i s h e r != n u l l )

n o t i f i c a t i o n P u b l i s h e r . s e n d N o t i f i c a t i o n (new N o t i f i c a t i o n (" MetadataChange " , t h i s , 0 , g e t M e t a d a t a I d e n t i f i e r ( ) + " reloaded " ) ) ;

}}

Listing 5.5: ResourceBackedMetadataProvider

Listing 5.6 illustrates how all metadata providers of typeResourceBackedMetadataProvider are registered as MBeans. For identification of theMBean the objectName is dynamically defined using the metadata identifier (e.g., thefilename).pub l i c c l a s s SAMLMDRely ingPartyConf igurat ionManager extends B a s e R e l o a d a b l e S e r v i c e

implements R e l y i n g P a r t y C o n f i g u r a t i o n M a n a g e r {

p r i v a t e vo id r eg i s t e rResou rceBackedMetada taProv ide rMBeans ( MBeanExporter e x p o r t e r ) {Cha in i ngMetada taProv i de r c h a i n i n g M e t a d a t a P r o v i d e r ;t r y {

c h a i n i n g M e t a d a t a P r o v i d e r = ( Cha in i ngMetada taProv i de r ) ge tMetada taProv i de r ( ) ;} catch ( C l a s s C a s t E x c e p t i o n e ) {

l o g . e r r o r ( "Sorry , assuming ChainingMetadataProvider " ) ;r e t u r n ;

}

f o r ( MetadataProv ide r metada taProv ide r : c h a i n i n g M e t a d a t a P r o v i d e r . g e t P r o v i d e r s ( ) ) {ResourceBackedMetadataProv ide r p r o v i d e r ;t r y {

p r o v i d e r = ( ResourceBackedMetadataProv ide r ) metada taProv ide r ;

33

} catch ( C l a s s C a s t E x c e p t i o n e ) {l o g . warn ( "Sorry , {} not supported , yet" , me tada taProv ide r . g e t C l a s s ( ) ) ;cont inue ;

}

ObjectName objectName = n u l l ;t r y {

objectName = new ObjectName (" mseproject :type=Metadata ,name="+p r o v i d e r . g e t M e t a d a t a I d e n t i f i e r ( ) ) ;

} catch ( MalformedObjectNameExcept ion e ) {l o g . e r r o r ( "{}" , e ) ;

}e x p o r t e r . r e g i s t e r M a n a g e d R e s o u r c e ( p r o v i d e r , objectName ) ;

}}

. . .

pro tec ted vo id onNewContextCreated ( A p p l i c a t i o n C o n t e x t newSe rv i c eContex t )throws S e r v i c e E x c e p t i o n {

. . .MBeanExporter e x p o r t e r = ( MBeanExporter ) newSe rv i c eContex t . getBean ( " exporter " ) ;e x p o r t e r . s e t R e g i s t r a t i o n B e h a v i o r ( MBeanExporter . REGISTRATION_REPLACE_EXISTING ) ;r eg i s t e rResou rceBackedMetada taProv ide rMBeans ( e x p o r t e r ) ;

}}

Listing 5.6: SAMLMDRelyingPartyConfigurationManager

5.5.4. AuthenticationThe Shibboleth IdP supports several authentication methods (e.g., username and pass-word, previous sessions etc.).Each method is configured and provided by a LoginHandler. To support the requiredJMX functionalities and be independent of a specific LoginHandler the introduction ofa generic AuthenticationMBean was necessary.

Figure 5.1 illustrates the relations between the LoginHandlers and theAuthenticationMBean. The interface LoginHandler contains methods for managinglogin counts of different results (i.e., successful, failed). The AbstractLoginHandlerprovides implementations for those methods as well as other convenient operations likeincrement etc., which are used by the concrete classes(e.g., PreviousSessionLoginHandler and UsernamePasswordLoginHandler) then.

Each AuthenticationMBean knows its LoginHandler in an association relationship andcontains the @ManagedAttribute annotations for getting the count of successful andfailed authentications as well the @ManagedOperation annotations for resetting the coun-ters.

34

<<interface>>

LoginHandlerLOGIN_RESULT_SUCCESS: intLOGIN_RESULT_FAIL: intgetLoginCount(int loginResult): intresetLoginCount(int loginResult)

AbstractLoginHandlerloginCount: ConcurrentMap<Integer, Integer>getLoginCount(int loginResult): intresetLoginCount(int loginResult)setLoginCount(int loginResult, int count)incrementLoginCount(int loginResult)

AuthenticationMBeanloginHandler: LoginHandlerAuthenticationMBean(LoginHandler loginHandler)getSuccessfulAuthentications: intgetFailedAuthentications: intresetSuccessfulAuthentications()resetFailedAuthentications()

UsernamePasswordLoginHandlerPreviousSessionLoginHandler

Figure 5.1.: AuthenticationMBean

Listing 5.7 shows the registration of a AuthenticationMBean for each configuredLoginHandler. The objectName is created dynamically by the LoginHandler’s classname.pub l i c c l a s s A u t h e n t i c a t i o n E n g i n e extends H t t p S e r v l e t {

pub l i c vo id i n i t ( S e r v l e t C o n f i g c o n f i g ) throws S e r v l e t E x c e p t i o n {. . .r e g i s t e r A u t h e n t i c a t i o n M B e a n s ( ) ;

}

. . .

p r i v a t e vo id r e g i s t e r A u t h e n t i c a t i o n M B e a n s ( ) {WebApp l i ca t ionContex t c o n t e x t =

W e b A p p l i c a t i o n C o n t e x t U t i l s . g e tWebApp l i ca t i onContex t ( g e t S e r v l e t C o n t e x t ( ) ) ;MBeanExporter e x p o r t e r = ( MBeanExporter ) c o n t e x t . getBean ( " exporter " ) ;f o r ( Log inHand l e r l o g i n H a n d l e r : hand le rManager . g e t L o g i n H a n d l e r s ( ) . v a l u e s ( ) ) {

Authent icat ionMBean mbean = new Authent icat ionMBean ( l o g i n H a n d l e r ) ;ObjectName objectName = n u l l ;t r y {

objectName = new ObjectName ( " mseproject :type= Authentication ,name="+l o g i n H a n d l e r . g e t C l a s s ( ) . getSimpleName ( ) ) ;

} catch ( MalformedObjectNameExcept ion e ) {LOG. e r r o r ( "{}" , e ) ;

}e x p o r t e r . r e g i s t e r M a n a g e d R e s o u r c e ( mbean , objectName ) ;

}}

}

Listing 5.7: AuthenticationEngine

35

UsernamePasswordLoginHandler

This section contains the enablement of the UsernamePasswordLoginHandler as MBean.

Because the UsernamePasswordLoginHandler is not able to decide if an authenticationwas successful, it has to delegate the task to the UsernamePasswordLoginServlet. SeeListing 5.8.pub l i c c l a s s UsernamePasswordLoginHandler extends A b s t r a c t L o g i n H a n d l e r {

. . .pub l i c vo id l o g i n ( f i n a l H t t p S e r v l e t R e q u e s t ht tpRequest ,

f i n a l H t t p S e r v l e t R e s p o n s e ht tpResponse ) {. . .h t tpReques t . g e t S e s s i o n ( ) . s e t A t t r i b u t e ( t h i s . g e t C l a s s ( ) . getName ( ) , t h i s ) ;. . .h t tpResponse . s e n d R e d i r e c t ( a u t h e n t i c a t i o n S e r v l e t U R L ) ;

}}

Listing 5.8: UsernamePasswordLoginHandler

Listing 5.9 describes how the UsernamePasswordLoginServlet increments the respec-tive counter for successful or failed authentications.pub l i c c l a s s Use rnamePasswordLog inSe rv l e t extends H t t p S e r v l e t {

. . .pro tec ted vo id s e r v i c e ( H t t p S e r v l e t R e q u e s t r e q ue s t , H t t p S e r v l e t R e s p o n s e r e s p o n s e )

throws S e r v l e t E x c e p t i o n ,. . .UsernamePasswordLoginHandler l o g i n H a n d l e r = ( UsernamePasswordLog inHandler )

r e q u e s t . g e t S e s s i o n ( ) . g e t A t t r i b u t e ( UsernamePasswordLoginHandler . c l a s s. getName ( ) ) ;

t r y {a u t h e n t i c a t e U s e r ( r e q u e s t , username , password ) ;l o g i n H a n d l e r . i nc rementLog inCount ( Log inHand l e r . LOGIN_RESULT_SUCCESS ) ;A u t h e n t i c a t i o n E n g i n e . r e t u r n T o A u t h e n t i c a t i o n E n g i n e ( r e q ue s t , r e s p o n s e ) ;

} catch ( L o g i n E x c e p t i o n e ) {r e q u e s t . s e t A t t r i b u t e ( f a i l u r e P a r a m , "true" ) ;r e q u e s t . s e t A t t r i b u t e ( Log inHand l e r . AUTHENTICATION_EXCEPTION_KEY,

new A u t h e n t i c a t i o n E x c e p t i o n ( e ) ) ;l o g i n H a n d l e r . i nc rementLog inCount ( Log inHand l e r . LOGIN_RESULT_FAIL ) ;r e d i r e c t T o L o g i n P a g e ( r e q u e s t , r e s p o n s e ) ;

}}. . .

}

Listing 5.9: UsernamePasswordLoginServlet

PreviousSessionLoginHandler

This section contains the enablement of the PreviousSessionLoginHandler as MBean.

In contrary to the UsernamePasswordLoginHandler the PreviousSessionLoginHandleris able to decide if an authentication was successful or not. Listing 5.10 illustrates theimplementation.

36

pub l i c c l a s s P r e v i o u s S e s s i o n L o g i n H a n d l e r extends A b s t r a c t L o g i n H a n d l e r {. . .pub l i c vo id l o g i n ( H t t p S e r v l e t R e q u e s t ht tpRequest , H t t p S e r v l e t R e s p o n s e ht tpResponse ) {

. . .S e s s i o n i d p S e s s i o n = ( S e s s i o n ) h t tpReques t . g e t A t t r i b u t e (

S e s s i o n . HTTP_SESSION_BINDING_ATTRIBUTE ) ;i f ( i d p S e s s i o n == n u l l ) {

l o g . warn ( "No existing IdP session available ." ) ;h t tpReques t . s e t A t t r i b u t e ( Log inHand l e r .AUTHENTICATION_ERROR_KEY,

"No existing IdP session available " ) ;i nc rementLog inCount ( Log inHand l e r . LOGIN_RESULT_FAIL ) ;

} e l s e {l o g . debug ( " Using existing IdP session for {}" , i d p S e s s i o n . ge tP r i n c i pa lName ( ) ) ;h t tpReques t . s e t A t t r i b u t e ( Log inHand l e r . PRINCIPAL_NAME_KEY,

i d p S e s s i o n . ge tP r i nc i pa lName ( ) ) ;i nc rementLog inCount ( Log inHand l e r . LOGIN_RESULT_SUCCESS ) ;

}A u t h e n t i c a t i o n E n g i n e . r e t u r n T o A u t h e n t i c a t i o n E n g i n e ( ht tpRequest , h t tpResponse ) ;

}. . .

}

Listing 5.10: PreviousSessionLoginHandler

5.5.5. Attribute ProcessingThis section touches the performance MBean, which provides statistics about attributeprocessing. It is realized with the Perf4J @Profiled annotation as introduced in Sec-tion 3.3.

Listing 5.11 illustrates the profiling of the resolveAttributes(...) method.pub l i c c l a s s S h i b b o l e t h A t t r i b u t e R e s o l v e r extends B a s e R e l o a d a b l e S e r v i c e implements

A t t r i b u t e R e s o l v e r <SAMLProf i l eRequestContext > {

@ P r o f i l e d ( tag=" attributes . resolve " , l o g g e r=" mseproject . attributeprocessing " )pub l i c Map<S t r i n g , B a s e A t t r i b u t e > r e s o l v e A t t r i b u t e s (

SAMLProf i l eRequestContext a t t r i b u t e R e q u e s t C o n t e x t )throws A t t r i b u t e R e s o l u t i o n E x c e p t i o n { . . . }

. . .}

Listing 5.11: ShibbolethAttributeResolver

Listing 5.12 illustrates the profiling of the filterAttributes(...) method.}

pub l i c c l a s s S h i b b o l e t h A t t r i b u t e F i l t e r i n g E n g i n e extends B a s e R e l o a d a b l e S e r v i c e implementsA t t r i b u t e F i l t e r i n g E n g i n e <SAMLProf i l eRequestContext > {

@ P r o f i l e d ( tag=" attributes . filter " , l o g g e r=" mseproject . attributeprocessing " )pub l i c Map<S t r i n g , B a s e A t t r i b u t e > f i l t e r A t t r i b u t e s (

Map<S t r i n g , B a s e A t t r i b u t e > a t t r i b u t e s , SAMLProf i l eRequestContext c o n t e x t )throws A t t r i b u t e F i l t e r i n g E x c e p t i o n { . . . }

. . .}

Listing 5.12: ShibbolethAttributeFilteringEngine

37

For exposing the performance data in an MBean the loggermseproject.attributeprocessing has to supplemented by a JMX appender. See Sec-tion 6.2.

38

6. IntegrationThis chapter documents the integration of the new features provided by the JMX enabledIdP into the monitoring system Nagios.

6.1. JMX MonitorsListing 6.1 shows the instantiation of some monitors which are MBeans for itself again.The illustrated configuration provides a status monitor which every minute checks thestatus of the IdP and publishes notification in case of a failure.

For each AuthenticationMBean a monitor configured in DifferenceMode provides therate of successful and failed logins per minute. Optionally, a threshold (e.g., failed user-name password logins per minute) can be enabled.

These monitors can be used stand-alone by the JConsole or Nagios.<?xml v e r s i o n="1.0" encod ing="UTF -8"?>

<beans xmlns=" http: // www. springframework .org/ schema / beans "4 x m l n s : x s i=" http: // www.w3.org /2001/ XMLSchema - instance "

x s i : s c h e m a L o c a t i o n=" http: // www. springframework .org/ schema / beanshttp: // www. springframework .org/ schema / beans /spring - beans .xsd">

<!−− Monitor MBeans −−>9 <bean i d=" mseproject . monitor . status "

c l a s s=" javax . management . monitor . StringMonitor " i n i t −method=" start ">

14 

</ bean>

19 <bean i d=" mseproject . monitor . authentication . usernamepassword .spm"c l a s s=" javax . management . monitor . CounterMonitor " i n i t −method=" start ">



24 

</ bean>

<bean i d=" mseproject . monitor . authentication . usernamepassword .fpm"29 c l a s s=" javax . management . monitor . CounterMonitor " i n i t −method=" start ">





39

34 

</ bean>

39 <bean i d=" mseproject . monitor . authentication . previoussession .spm"c l a s s=" javax . management . monitor . CounterMonitor " i n i t −method=" start ">



44 

</ bean>

<bean i d=" mseproject . monitor . authentication . previoussession .fpm"49 c l a s s=" javax . management . monitor . CounterMonitor " i n i t −method=" start ">





54 </ bean>

</ beans>

Listing 6.1: internal-jmx-monitor.xml

6.2. Perf4J and Logback SMTP AppendersListing 6.2 illustrates one part of the Logback configuration. There are several appendersand loggers configured:

FILE Logging events from the LoggingNotificationListener, see Section 3.2.4,are appended to a file.

EMAIL Logging events from the LoggingNotificationListener are sent by e-mail using the Simple Mail Transfer Protocol (SMTP) appender.

mseproject The logger which upstreams the logging event to the FILE and EMAILappender.

For the Perf4J configuration following loggers and appenders are defined:

JMX This appender exposes performance statistics as attributes to aJMX MBean. In addition it allows you to set thresholds for thesestatistics and send notifications when the logged values exceedthe thresholds.

Graph The GraphingStatisticsAppender uses theGroupedTimingStatistics to generate performance graphs. Thesegraphs, which are implemented as URLs using the Google ChartAPI to create the actual graph images, can be displayed in abrowser.

40

AttributeProcessing The logger which upstreams the Perf4J performance data to theJMX and the graph appender.

<!−− A F i l e Appender −−>

3 <appender name="FILE" c l a s s="ch.qos. logback .core. FileAppender "><F i l e>/ opt / s h i b b o l e t h−i d p / l o g s / m s e p r o j e c t . l o g</ F i l e><Immed ia teF lush>t r u e</ Immed ia teF lush><l a y o u t c l a s s="ch.qos. logback . classic . PatternLayout ">

%date {HH:mm:ss . SSS} − %l e v e l [% l o g g e r :%l i n e ] − %msg%n</ Pat t e r n>8 </ l a y o u t>

</ appender>

<!−− A SMTP Appender −−><appender name=" EMAIL " c l a s s="ch.qos. logback . classic .net. SMTPAppender ">

13 <SMTPHost>l o c a l h o s t</SMTPHost><To>r o o t @ l o c a l h o s t</To><From>r o o t @ l o c a l h o s t</From><S u b j e c t>JMX n o t i f i c a t i o n</ S u b j e c t><l a y o u t c l a s s="ch.qos. logback . classic . PatternLayout ">

18 %date %message%n</ Pat t e r n></ l a y o u t>

</ appender>

<!−− Main Logger −−>23 <l o g g e r name=" mseproject ">

< l e v e l v a l u e="ALL" /><appender−r e f r e f="FILE" /><appender−r e f r e f=" EMAIL " />

</ l o g g e r>28

<!−− Per f4J C o n f i g u r a t i o n −−>

<!−− A t t r i b u t e P r o c e s s i n g : JMX Appender −−>33 <appender name=" mseproject . statistics . attributeprocessing .jmx"

c l a s s=" mseproject . perf4j . slf4j . JmxAttributeStatisticsAppender "><param name=" TagNamesToExpose " v a l u e=" attributes .resolve , attributes . filter " /><param name=" NotificationThresholds " v a l u e=" attributes . resolveMax (& lt ;200) " /><param name=" MBeanName "

38 v a l u e=" mseproject:type = Performance ,name= AttributeProcessing "/></ appender>

<!−− A t t r i b u t e P r o c e s s i n g : Graph Output Appender −−><appender name=" mseproject . statistics . attributeprocessing . graph .file"

43 c l a s s="ch.qos. logback .core. FileAppender "><param name="File" v a l u e="/tmp/ attributeprocessing . graph .log"/><l a y o u t c l a s s="ch.qos. logback . classic . PatternLayout ">

%message%n</ Pa t t e rn></ l a y o u t>

48 </ appender>

<!−− A t t r i b u t e P r o c e s s i n g : Graph S t a t i s t i c s Appender −−><appender name=" mseproject . statistics . attributeprocessing . graph "

c l a s s=" mseproject . perf4j . slf4j . GraphingStatisticsAppender ">53 <param name=" GraphType " v a l u e="Mean"/>

<param name=" TagNamesToGraph " v a l u e=" attributes .resolve , attributes . filter "/><param name=" DataPointsPerGraph " v a l u e="1"/><appender−r e f r e f=" mseproject . statistics . attributeprocessing . graph .file"/>

</ appender>58

<!−− A t t r i b u t e P r o c e s s i n g : S t a t i s t i c s Appender −−><appender name=" mseproject . statistics . attributeprocessing "

c l a s s=" mseproject . perf4j . slf4j . AsyncCoalescingStatisticsAppender "><param name=" TimeSlice " v a l u e=" 60000 " />

41

63 <appender−r e f r e f=" mseproject . statistics . attributeprocessing .jmx" /><appender−r e f r e f=" mseproject . statistics . attributeprocessing . graph "/>

</ appender>

<!−− A t t r i b u t e P r o c e s s i n g : Logger −−>68 <l o g g e r name=" mseproject . attributeprocessing " a d d i t i v i t y=" false ">

< l e v e l v a l u e="INFO" /><appender−r e f r e f=" mseproject . statistics . attributeprocessing " />

</ l o g g e r>

Listing 6.2: logging-jmx.xml

6.3. NagiosNagios is a powerful monitoring system and provides an extensible plug-in concept. Forthis integration a JMX Nagios plug-in [14] was utilized and customized.

6.3.1. JMX Plug-inThe requirements to Nagios plug-ins are that the output should be in the format:

SERVICE STATUS: Information text

as well as the return (status) code is one of this set:0 OK1 WARNING2 CRITICAL3 UNKNOWN

Performance data is defined by Nagios as “everything after the | of the plug-in output”The expected performance data format must respect the following specification:

’label’=value[UOM];[warn];[crit];[min];[max]

The used Nagios JMX plug-in provides most of the required features. Some customiza-tion was needed, see Section 6.3.2.

6.3.2. ConfigurationListing 6.3 illustrates the definition of the used JMX plug-in commands. For most servicemonitoring the check_idp command (Listing 6.4) is sufficient but for the authentica-tion (check_idp_authentications, Listing 6.5) and attribute processing performance(check_idp_attributeprocessing, Listing 6.6) statistics an extension was required.# F u r t h e r command d e f i n i t i o n s omi t ted

d e f i n e command {command_name check_idpcommand_line / opt / nag io s−jmx−p l u g i n / check_jmx \

−U s e r v i c e : jmx : rmi :/// j n d i / rmi : // l o c a l h o s t :1099/ jmx \

42

−O m s e p r o j e c t : t ype=$ARG1$ , name=$ARG2$ −A $ARG3$ $ARG4$}

d e f i n e command {command_name c h e c k _ i d p _ a u t h e n t i c a t i o n scommand_line / opt / nag io s−jmx−p l u g i n / c h e c k _ a u t h e n t i c a t i o n s \

−U s e r v i c e : jmx : rmi :/// j n d i / rmi : // l o c a l h o s t :1099/ jmx \−O m s e p r o j e c t : t ype=A u t h e n t i c a t i o n , name=$ARG1$ $ARG2$

}

d e f i n e command {command_name c h e c k _ i d p _ a t t r i b u t e p r o c e s s i n gcommand_line / opt / nag io s−jmx−p l u g i n / c h e c k _ a t t r i b u t e p r o c e s s i n g \

−U s e r v i c e : jmx : rmi :/// j n d i / rmi : // l o c a l h o s t :1099/ jmx \−O m s e p r o j e c t : t ype=Performance , name=A t t r i b u t e P r o c e s s i n g

}

Listing 6.3: commands.cfg

check_idp

Listing 6.4 demonstrates the usage of the Nagios JMX plug-in check_idp command. Itis possible to query an arbitrary attribute of an MBean and optionally specify thresholdsfor warning and critical values.# / opt / nag ios−jmx−p l u g i n / check_jmx \−U s e r v i c e : jmx : rmi :/// j n d i / rmi : // l o c a l h o s t :1099/ jmx \−O m s e p r o j e c t : type=Management , name=S e s s i o n \−A Count −w 50 −c 100

Listing 6.4: check_idp

The output might look like:

JMX OK - Count = 7 | ’Count’=7;50;100;;

check_idp_authentications

Listing 6.5 demonstrates the extension of the check_idp script, which provides multipleperformance outputs. In this case for successful as well failed authentications.# / opt / nag ios−jmx−p l u g i n / c h e c k _ i d p _ a u t h e n t i c a t i o n s \−U s e r v i c e : jmx : rmi :/// j n d i / rmi : // l o c a l h o s t :1099/ jmx \−O m s e p r o j e c t : type=A u t h e n t i c a t i o n , name=UsernamePassword −w 3 −c 5

Listing 6.5: check_idp_authentications


JMX CRITICAL - failedAuthentications = 5 | \’sucessfulAuthentications’=3;;;; ’failedAuthentications’=5;3;5;;

43

check_idp_attributeprocessing

Listing 6.6 demonstrates the extension of the check_idp script, which provides min/maxvalues to the performance output.# / opt / nag ios−jmx−p l u g i n / c h e c k _ i d p _ a t t r i b u t e p r o c e s s i n g \−U s e r v i c e : jmx : rmi :/// j n d i / rmi : // l o c a l h o s t :1099/ jmx \−O m s e p r o j e c t : type=Performance , name=A t t r i b u t e P r o c e s s i n g

Listing 6.6: check_idp_attributeprocessing


JMX OK - mseproject:type=Performance,name=AttributeProcessing | \’attributes.resolve’=10.0;;;8;13 ’attributes.filter’=0.9;;;0;1

Listing 6.7 illustrates an excerpt of an example Nagios service configuration which makesuse of the previously defined commands.# F u r t h e r hos t and s e r v i c e group d e f i n i t i o n s omi t ted

d e f i n e s e r v i c e {name a b s t r a c t−jmx−s e r v i c ehost_name id p . example . orgs e r v i c e g r o u p s IdP

max_check_attempts 1c h e c k _ i n t e r v a l 60check_pe r i od 24 x7

c o n t a c t s r e u s s e rn o t i f i c a t i o n _ p e r i o d 24 x7n o t i f i c a t i o n _ i n t e r v a l 0

p r o c e s s _ p e r f _ d a t a 0}

d e f i n e s e r v i c e {name graphp r o c e s s _ p e r f _ d a t a 1a c t i o n _ u r l / pnp4nag ios / graph ? hos t=$HOSTNAME$&s r v=$SERVICEDESC$

}

d e f i n e s e r v i c e {use a b s t r a c t−jmx−s e r v i c es e r v i c e _ d e s c r i p t i o n s t a t u scheck_command check_idp ! I n f o r m a t i o n ! S t a t u s ! S t a t u s −w @WARNING −c @CRITICAL

}

d e f i n e s e r v i c e {use graph , a b s t r a c t−jmx−s e r v i c es e r v i c e _ d e s c r i p t i o n s e s s i o n scheck_command check_idp ! Management ! S e s s i o n ! Count ! −w 50 −c 100

}

d e f i n e s e r v i c e {use graph , a b s t r a c t−jmx−s e r v i c es e r v i c e _ d e s c r i p t i o n a u t h e n t i c a t i o n s−username−passwordcheck_command c h e c k _ i d p _ a u t h e n t i c a t i o n s ! UsernamePassword ! −w 3 −c 5

}

d e f i n e s e r v i c e {use a b s t r a c t−jmx−s e r v i c e

44

s e r v i c e _ d e s c r i p t i o n idp−metadata−e x p i r echeck_command check_idp ! Metadata !\

/ e t c / s h i b b o l e t h /sp−metadata . xml ! E x p i r a t i o n D a t e}

d e f i n e s e r v i c e {use graph , a b s t r a c t−jmx−s e r v i c es e r v i c e _ d e s c r i p t i o n a t t r i b u t e p r o c e s s i n gcheck_command c h e c k _ i d p _ a t t r i b u t e p r o c e s s i n g

}

# s e r v i c e d e f i n i t i o n s omi t ted

Listing 6.7: idp.example.org.cfg

6.3.3. PNP4NagiosPNP4Nagios [17] is a plug-in for Nagios which allows to visualize performance data usingRRD graphs [18]. Via a template based system it is possible to customize style, labelsand resolution of the graphs. The custom templates which configure the rrdgraph arefound on the DVD (Appendix F). See Section 8 for example graphs.

45

7. TestingFor testing the counter or performance MBeans one needs to simulate IdP logins. Thefollowing authentication types are distinguished:

Successful authentication A user — without any SSO session — authenticatessuccessfully at the IdP using valid credentials (e.g.,username and password).

Failed authentication A user — without any SSO session — authenticatesunsuccessfully at the IdP using invalid credentials(e.g., wrong password).

Previous session authentication A user — with a valid SSO session — authenticatessuccessfully at the IdP without using any creden-tials.

The objective is to simulate those 3 authentication types repeated in a random fashion.Another concern is to have a random delay between each authentication as well using arandom account per login.

7.1. Canoo WebtestCanoo’s webtest framework [2] fits very well for implementing the needed simulation.Listing 7.1 defines a generic test for a Shibboleth authentication, intended to be param-eterized according the needs.

This generic test consists of the following main steps:

1. Choose a random number within the configured interval→ login iterations (Line 10).

2. Randomly decide if an IdP logout should be done (Line 12).

3. Access the SP (Line 18).

4. Check if a logout was archived (Line 21).a) If the IdP’s login page appears, fill out the login form

i. Choose a random user account (Line 24).ii. Choose a random password — valid or invalid — (Line 26).iii. Check if authentication was successful (Line 34) or not (Line 38).

46

b) Else check the attribute page of the SP (Line 43).

5. Choose a random number within the configured interval → delay for the nextiteration (Line 47).

<?xml v e r s i o n="1.0"?>

4 <impor t f i l e ="${ webtest .home }/ webtest .xml"/>

<t a r g e t name="wt. testInWork "><webte s t name="random - logins ">

<c o n f i g u s e I n s e c u r e S S L="true"/>9 <s t e p s>

<storeRandom p rope r t y=" repeat " from="${ repeat .from}" to="${ repeat .to}"/><r e p e a t count="#{ repeat }">

<storeRandom p rope r t y=" logout " c h o i c e="${ logout . random }"/>

14 <groovy>s t e p . c o n t e x t . webC l i en t . cook ieManager . c l e a r C o o k i e s ( )

</ groovy>

19 <cond i t i o n>

< v e r i f y T i t l e t e x t="${ idp. title }"/></ cond i t i o n><then>

24 <storeRandom p rope r t y="user" c h o i c e="${ username . random }"/><s e t I n p u t F i e l d name="${ idp. usernamefield }" v a l u e="#{ user}"/><storeRandom p rope r t y=" password " c h o i c e="${ password . random }"/><s e t I n p u t F i e l d name="${ idp. passwordfield }" v a l u e="#{ password }"/><c l i c k B u t t o n l a b e l="${ idp. loginbutton }"/>

29 <cond i t i o n>

<v e r i f y P r o p e r t y p rope r t y="#{ password }" t e x t="${ password . valid }"/></ cond i t i o n><then>

34 < v e r i f y T i t l e t e x t="${ sp. title }"/><v e r i f y T e x t t e x t="#{ user }${ sp. attribute }"/>

</ then><e l s e>

<v e r i f y T e x t t e x t="${ idp. authnFailed }"/>39 </ e l s e>

</ then><e l s e>

< v e r i f y T i t l e t e x t="${ sp. title }"/>44 <v e r i f y T e x t t e x t="#{ user }${ sp. attribute }"/>

</ e l s e><storeRandom p rope r t y=" delay " from="${ delay .from}" to="${ delay .to}"/><s l e ep s econds="#{ delay }"/>

49 </ r e p e a t></ s t e p s>

</ webte s t></ t a r g e t>



Listing 7.1: Shibboleth Login Test

Listing 7.2 illustrates how such a test can be parameterized. The explanation of eachconfiguration option is inline within this properties file.

47

webte s t . home=/Use r s / r e u s s e r /MSE/ P r o j e k t / b i n / webte s t2 sp . u r l=h t t p s : // sp . example . org / S h i b b o l e t h . s s o / Logout ? r e t u r n=h t t p s : // sp . example . org / t e s t /

sp . t i t l e =S h i b b o l e t h A t t r i b u t e s

# Check f o r an u s e r a t t r i b u t esp . a t t r i b u t e=@example . org

7# IdP l o g i n pagei d p . t i t l e =S h i b b o l e t h I d e n t i t y P r o v i d e r − Log ini d p . u s e r n a m e f i e l d=j_usernameid p . p a s s w o r d f i e l d=j_password

12 i d p . a u t h n F a i l e d=A u t h e n t i c a t i o n F a i l e di d p . l o g i n b u t t o n=Log in

# Random l o g i n s between from and to# Only one l o g i n : from =0, to=1

17 # Exact 5 l o g i n s : from =5, to=6r e p e a t . from=500r e p e a t . to =100001

# Random l o g i n d e l a y s between from and to22 # No d e l a y : from =0, to=1

# Exact 5 s e c o n d s : from =5, to=6d e l a y . from=0d e l a y . to=60

27 # Random u s e r c h o i c e# I f o n l y one u s e r =s t u d e n t 1username . random=student1 , s tudent2 , s t a f f 1 , s t a f f 2 , alum1

# Only v a l i d l o g i n s =password32 # 3/4 v a l i d l o g i n s , 1/4 i n v a l i d l o g i n s =password , password , password , wrong

password . random=password , password , password , password , password , password , password , wrongpassword . v a l i d=password

# Only fo r ceAuthn =t r u e37 # 3/4 forceAuhtn , 1/4 p r e v i o u s S e s s i o n =true , t rue , t rue , f a l s e

l o g o u t . random=true , t rue , t rue , f a l s e

Listing 7.2: Test Configuration

Due to this flexible webtest it is easy to provide various simulations for testing thecounter or performance MBeans.

48

8. Use CasesThis chapter shows some of the use cases for the implemented MBeans as well as theirintegration into the Nagios monitoring system.

8.1. ClientsAll managed attributes and managed operations are accessible by the JConsole or theHTTP adaptor (i.e., all attributes can be read, writable attributes can be set, operationscould be executed — with any arguments — and return values might be examined).

8.1.1. JConsoleThe easiest way to monitor and manage MBeans is the usage of the JConsole, which isdistributed with the Java Runtime Environment (JRE). Figure 8.1 shows the usage ofthe JConsole. Note that numeric attributes can be monitored in a chart.

Figure 8.1.: JConsole

49

All JMX notifications which are sent can be caught using the JConsole by subscribingto the corresponding notification(s).

8.1.2. HTTP AdaptorFigure 8.2 illustrates the HTML view of an MBean provided by the HTTP adaptor.

Figure 8.2.: HTTP Adaptor

8.1.3. Nagios ConsoleFor all attributes observed by Nagios (one minute frequency) an e-mail is sent if aWARNING or CRITICAL threshold is configured and reached.

50

8.2. Managed ComponentsThis section shows for each implemented MBean its managed attributes and operations,its monitors and notifications if available as well as provided statistic graphs and ademonstration case.

8.2.1. Status informationThe following MBean provides the status information of the IdP:objectName="mseproject:type=Information,name=Status"

Managed Attributes

Attribute Description r/wStarttime Start date and time of the IdP rUptime Uptime in seconds of the IdP rStatus Status of the IdP (OK|WARNING|CRITICAL) rStatuscode Statuscode OK=0, WARNING=1, CRITICAL=2 rVersion IdP version r

Monitors & Notifications

The mseproject:type=Information,name=StatusMonitor MBean checks every minutethe attribute Status 6= OK and sends a JMX notification.

Nagios (see Figure 8.3) checks every minute the status of the IdP. In case of a WARNINGor CRITICAL state the color changes to orange respectively red. According to the Nagiosnotification configuration an e-mail is sent.

Figure 8.3.: IdP Status

Graphs

None.

Demonstration

A simple way for triggering an error on the IdP side is to make the directory serviceunavailable (Listing 8.1).

51

# s e r v i c e apacheds s top

Listing 8.1: Stopping the Apache Directory Service

After the next check of Nagios, the web console display the CRITICAL state. See Fig-ure 8.4.

Figure 8.4.: IdP Status

Nagios sends a notification e-mail as well. See Listing 8.2.Date : Wed, 2 Jun 2010 1 6 : 0 7 : 0 3 +0200From : n a g i o s <nag io s@pr imave ra >To : roo t@pr imave raS u b j e c t : ∗∗ PROBLEM S e r v i c e A l e r t : S h i b b o l e t h I d e n t i t y P r o v i d e r / s t a t u s i s CRITICAL ∗∗

∗∗∗∗∗ Nagios ∗∗∗∗∗

N o t i f i c a t i o n Type : PROBLEM

S e r v i c e : s t a t u sHost : S h i b b o l e t h I d e n t i t y P r o v i d e rAddress : i d p . example . orgS t a t e : CRITICAL

Listing 8.2: Nagios Problem Alert E-mail

8.2.2. Session ManagementThe IdP sessions are managed by the following MBean:objectName="mseproject:type=Management,name=Session"

Managed Attributes

Attribute Description r/wCount Current number of sessions rSessions List of current sessionIDs with associated principal r

Managed Operations

Operation Parameter Return valuedestroySession sessionIDdestroySessions number of destroyed sessions

52


Nagios checks every minute the current count of valid user sessions at the IdP. It isconfigured with thresholds for WARNING and CRITICAL values.

Figure 8.5 shows the session count in OK state.

Figure 8.5.: IdP Sessions

In case of a WARNING or, CRITICAL state the color changes to orange respectively red.According to the Nagios notification configuration an e-mail is sent.

Graphs

The number of sessions is periodically updated in a graph. Figure 8.6 visualizes thesession count over 4 hours. The orange respectively the red lines indicate the WARNINGand CRITICAL thresholds.

Figure 8.6.: IdP Sessions

Demonstration

Nagios as well as the graphs might be used to observe the current number of activesessions.

Figure 8.7.: Number of IdP Sessions

Another example might be an administrative logout. If the user student1 executes alogin, an IdP session is created, which enables SSO (i.e., as long as the IdP session is

53

valid, the user does not have to authenticate again). In the list of current sessionIDs thesession of student1 is listed as:38c6902637837befa316b23fb0c9e83270dec714b411b4ab4ef19ea59cd8892c=student1

The operator is now able to force a logout of the user by using the destroySessionmethod with the associated sessionID as argument.

8.2.3. Metadata ManagementFor each configured MetadataProvider of type ResourceBackedMetadataProvider anMBean is created dynamically using the following identifier:objectName="mseproject:type=Metadata,name=#MetadataResourceName#"

Managed Attributes

Attribute Description r/wExpirationDate The expiration date of the metadata rLastRefreshDate The last refresh of the metadata rLastUpdateDate The last update of the metadata rRequireValidMetadata Indicates if valid metadata is required r/w

Managed Operations

Operation Parameter Return valuerefresh


Nagios displays the available metadata information for every monitored provider, seeFigure 8.8.

Figure 8.8.: Nagios Metadata Overview

In the case of a metadata update, a notification of type MetadataChange is published.

Graphs

None.

54

Demonstration

To enforce a metadata update, one could change the timestamp of the metadata file, seeListing 8.3.# touch / e t c / s h i b b o l e t h /sp−metadata . xml

Listing 8.3: Update Metadata Timestamp

After waiting for a specific time (next refresh) or manually executing the managedoperation refresh, the metadata is updated and a notification is sent, see Figure 8.9.

Figure 8.9.: MetadataChange Notification

8.2.4. AuthenticationFor each configured LoginHandler (e.g., UsernamePasswordLoginHandler,PreviousSessionLoginHandler etc.) an MBean is created dynamically using the fol-lowing identifier:objectName="mseproject:type=Authentication,name=#LoginHandlerName#"

Managed Attributes

Attribute Description r/wFailedAuthentications Current count of failed authentications rSuccessfulAuthentications Current count of successful authentications r

Managed Operations

It is allowed to reset both counters to zero if it is required for some reasons.Operation Parameter Return valueresetFailedAuthenticationsresetSuccessfulAuthentications


For each pair of LoginHandler and successful respectively failed authentications ajavax.management.monitor.CounterMonitor in differenceMode is defined with aconfigured granularity period of one minute. This allows to measure the count of specificauthentication types per minute and the definition of thresholds.

55

Graphs

Figures 8.10 and 8.11 illustrate the login statistics of username password authenticationsover different periods.

Figure 8.10.: Username Password 1h

Figure 8.11.: Username Password 1d

Figures 8.12 and 8.13 illustrate the login statistics of previous session authenticationsover different periods.

56

Figure 8.12.: Previous Session 1h

Figure 8.13.: Previous Session 1d

Demonstration

In case of exceeding the failed authentication threshold a notification is sent.

8.2.5. Attribute Processing PerformanceThe attribute processing performance data is available by the following MBean:objectName="mseproject:type=Performance,name=AttributeProcessing"

57

Managed Attributes

Attribute Description r/wattributes.resolveMean The mean of attribute resolving in the last period rattributes.resolveMin The min of attribute resolving in the last period rattributes.resolveMax The max of attribute resolving in the last period rattributes.resolveStdDev The min of attribute resolving in the last period rattributes.resolveCount The count of attribute resolvings in the last period rattributes.resolveTPS Attribute resolvings per second in the last period rattributes.filterMean The mean of attribute filtering in the last period rattributes.filterMin The min of attribute filtering in the last period rattributes.filterMax The max of attribute filtering in the last period rattributes.filterStdDev The min of attribute filtering in the last period rattributes.filterCount The count of attribute filterings in the last period rattributes.filterTPS Attribute filterings per second in the last period r

Managed Operations

None.


None. It is possible to define threshold ranges for specific performance data.

Graphs

Figure 8.14 shows the performance of the attribute resolving over 2 hours, visualizingmin, max and average values.

Figure 8.14.: Attribute Resolving

Figure 8.15 shows the performance of the attribute filtering over 2 hours, visualizingmin, max and average values.

58

Figure 8.15.: Attribute Filtering

Figure 8.16 shows the performance of the attribute resolving and filtering over 1 hourusing the Google Chart API.

Figure 8.16.: Attribute Processing

Demonstration

None.

59

9. ConclusionJMX-enabling an application can provide metrics and management tasks, which go farbeyond legacy monitoring approaches (SNMP, parsing log files etc.). JMX provides awide variety of possibilities to analyze, measure and change the run-time behavior of asystem.

The main benefits for service operators are the fine-grained metrics and managementtasks which provide high operation flexibility on one side and meaningful data aboutusage and performance on the other side.

This project demonstrated that enhancing the Shibboleth IdP with JMX support wouldconsiderably improve its scalable manageability.

9.1. ImplementationIf the application is well structured into components, the introduction of MBeans ispretty straightforward, especially if a supporting framework such as Spring is used. Theexcellent design of the Shibboleth IdP facilitates the activation of JMX for the individualcomponents.

The Spring JMX support using Java annotations is the most intuitive way to provideMBeans for an application. As outlined in Section 3.2 all major JMX functionalities areprovided by Spring. A shortcoming is the lack of inheritance support for JMX annota-tions, which leads to duplicate definitions. The Shibboleth IdP 3.x will use Spring 3.xwhere inheritance of JMX annotations is supported.

For profiling the IdP and measuring particular method execution performance, thePerf4J library including its JMX appender proved to be very useful.

Generally, the activation of JMX support within the IdP can be archived with a littleeffort and should not be left out from this state-of-the-art Java enterprise application.Therefore, the implementation for some major components should be considered in theShibboleth IdP 3.x.

60

9.2. IntegrationNagios is a typical network and infrastructure monitoring system with numerous plug-ins available for all sorts of system and application checking. The plug-in mechanismallows to write customized scripts with specified return values and information/perfor-mance data output. This flexibility has the drawbacks of maintaining these scripts andensuring compatibility.

The JMX Nagios plug-in used for querying the MBeans is a good start but has somelimitations like using/comparing non-number/string values (e.g., dates) and it doesn’tsupport the full Nagios performance data specification for min/max/avg data.

For organizations already operating a Nagios system, it could make sense to monitorcertain parameters of the IdP (e.g., the status, session count, failed authentications,metadata information etc.).

For more complex usage statistics and performance data some custom implementationbased on e.g., the Google Chart API as well as specific management scripts for oftenused operational tasks could be more efficient.

A promising solution might be the OpenNMS software [15], which is a pure Java net-work management system including rich JMX support. For other monitoring systemslike Munin [12] there are JMX plug-ins [11] available too, but were not considered inthis project.

For a light weight integration the out-of-the-box monitoring and management tools(e.g., JConsole, javax.management.monitor.*, LoggingListener together with Log-back SMTP appender, Perf4J chart appender etc.) might be sufficient.

9.3. OutlookThe insights and experiences of this project were shared with the Shibboleth IdP leaddeveloper Chad la Joie. The next major release of the Shibboleth IdP (3.0) will makeuse of the Spring JMX support to provide some components as MBeans.

61

GlossaryDiscovery Service The Discovery Service, also calledWhere Are You From (WAYF)

Service, lets the user select his IdP from a list and then redi-rects the user to the IdP’s login page for authentication.

Information Assurance Information assurance is the practice of managing risks relatedto the use, processing, storage, and transmission of informa-tion or data and the systems and processes used for thosepurposes.

Metadata Metadata is used to identify trusted IdPs and SPs. SWITCHprovides signed metadata for the SWITCHaai federation.

SWITCHaai The Shibboleth-based production federation in Swiss highereducation and research, coordinated and led by SWITCH.

62

AcronymsAAI Authentication and Authorization Infrastructure.AOP Aspect Orientated Programming.API Application Programming Interface.

FIM Federated Identity Management.

HTML Hypertext Markup Language.HTTP Hypertext Transfer Protocol.

IdP Identity Provider.IT Information Technology.

J2EE Java Platform Enterprise Edition.JMX Java Management Extensions.JRE Java Runtime Environment.JVM Java Virtual Machine.

LDAP Lightweight Directory Access Protocol.

MBean Managed Bean.MIB Management Information Base.

RADIUS Remote Authentication Dial-In User Service.RMI Remote Method Invocation.

SAML Security Assertion Markup Language.SLA Service Level Agreement.SMTP Simple Mail Transfer Protocol.SNMP Simple Network Management Protocol.SP Service Provider.SSO Single Sign On.

63

Bibliography[1] AMAAIS Project, 2010.

http://www.switch.ch/aaa/projects/detail/UZH.6.

[2] Canoo WebTest, 2010.http://webtest.canoo.com/.

[3] Google Chart API, 2010.http://code.google.com/apis/charttools/.

[4] Internet2 Shibboleth Project, 2010.http://shibboleth.internet2.edu/.

[5] Java Management Extensions (JMX), 2010.http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/.

[6] Java Management Extensions (JMX) on Wikipedia, 2010.http://en.wikipedia.org/wiki/Java_Management_Extensions.

[7] Java Platform, Standard Edition 6, API Specification, 2010.http://java.sun.com/javase/6/docs/api/.

[8] JMX - Best Practices, 2010.http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/best-practices.jsp.

[9] LDAP Metrics of the North Carolina State University, 2010.http://www.itd.ncsu.edu/about/metrics/ldap/201001.txt.

[10] Logback, 2010.http://logback.qos.ch/.

[11] Munin JMX Plug-in, 2010.http://exchange.munin-monitoring.org/plugins/jmx/details.

[12] Munin Monitoring, 2010.http://www.munin-monitoring.org/.

[13] Nagios - The Industry Standard in IT Infrastructure Monitoring, 2010.http://www.nagios.org/.

64

[14] Nagios JMX Plug-in, 2010.http://snippets.syabru.ch/nagios-jmx-plugin/.

[15] OpenNMS - Enterprise-grade Open-source Network Management, 2010.http://www.opennms.org.

[16] Perf4J, 2010.http://perf4j.codehaus.org/.

[17] PNP4Nagios, 2010.http://www.pnp4nagios.org/.

[18] RRDtool, 2010.http://oss.oetiker.ch/rrdtool/.

[19] SAML, 2010.www.oasis-open.org/committees/security/.

[20] Shibboleth Stats at University of Buffalo, 2010.https://ubidm.buffalo.edu/stats/.

[21] Simple Logging Facade for Java (SLF4J), 2010.http://www.slf4j.org/.

[22] Spring Framework, 2010.http://www.springsource.org/.

[23] SWITCHaai Federation, 2010.http://www.switch.ch/aai.

[24] Gail-Joon Ahn, Dongwan Shin, and Seng-Phil Hong. Information assurance infederated identity management: Experimentations and issues. In WISE, pages 78–89, 2004.

[25] P. Bhoj, S. Singhal, and S. Chutani. Sla management in federated environments.Comput. Netw., 35(1):5–24, 2001.

[26] Marc Fleury and Juha Lindfors. JMX: Managing J2EE Applications with JavaManagement Extensions. Sams, Indianapolis, IN, USA, 2001.

[27] James Won-KI Hong Jong-Tae Park, Jong-Wook Baek. Ip-oriented operations andmanagement. IEEE Communications Magazine, 2001.

[28] Adrian Paschke. A categorization scheme for sla metrics. In in Multi-ConferenceInformation Systems (MKWI06, 2006.

[29] G. Peterson. Introduction to identity management risk metrics. Security Privacy,IEEE, 4(4):88 –91, july-aug. 2006.

65

[30] M. K. Reiter and S. G. Stubblebine. Toward acceptable metrics of authentication.In SP ’97: Proceedings of the 1997 IEEE Symposium on Security and Privacy,Washington, DC, USA, 1997. IEEE Computer Society.

[31] Michael K. Reiter and Stuart G. Stubblebine. Authentication metric analysis anddesign. ACM Trans. Inf. Syst. Secur., 1999.

[32] SWITCHaai. Best current practices for operating a switchaai identity provider.Technical report, SWITCH, 2009.http://www.switch.ch/aai/bcp/.

[33] Manole Velicanu. Identity Management in University System, 2009.

66

A. Project proposalFrom: Halm ReusserTo: Andreas Steffen (HSR)Cc: Thomas Lenggenhager, Chad la Joie, Christoph Witzig (SWITCH)Date: 17. December 2009

MSE Project Thesis, Spring Semester 2010Project title: “JMX enabling the Shibboleth Identity Provider”Time period: 22. February 2010 – 16. July 2010 (21 weeks)Amount of time: 12 ECTS credits à 30 h = 360 h ≈ 43 days ≈ 2 days/week

IdeaThe main idea of the project is to enable the Shibboleth Identity Provider component [4]with Java management extension (JMX) [5] with focus to gain benefits for monitor-ing and management of identity federations like the Swiss SWITCHaai federation [23].JMX is a Java technology that supplies tools for managing and monitoring applica-tions. The AAA/SWITCH project AMAAIS [1] is working on monitoring concepts ofthe SWITCHaai federation.

Planed TasksDefining metrics (≈ 5 weeks):

• Figuring out what kind of service metrics could be measured, study research liter-ature.Applications, which may gather similar measure points: OpenSSO, LDAP measurepoints.

• Defining a set of metrics, in a structured manner are beneficial for the SWITCHaaifederation with the AMAAIS project.Example metrics: Number of Single Sign Ons, Performance, Last metadata refresh,Current sessions, . . .

67

• Defining a set of management tasks (e.g., update metadata, reload logging config-uration, . . . )

Enabling JMX at the Identity Provider (≈ 10 weeks):

• Concept and design for a clean consistent and flexible integration into the Shibbo-leth Identity Provider.

• Plan the packages for implementation depending on benefit to gain and effortrequired.

• Implementation of some (most beneficial) metrics and management tasks.

Proof of concept (≈ 5 weeks, in parallel to the implementation):

• Run test measurements and compare to classic measurements (log files).

The metric definition, concept and design as well as the results will be documented inthe project thesis final report.

Possible Extension to a Master ThesisThe project may be continued as a master thesis. An idea is to coordinate a pilotbetween the AMMAIS project in Switzerland and a similar monitoring project in theUnited Kingdom. There is no commitment yet.

Research AspectMonitoring of distributed systems is still a research topic. The SWITCHaai federationis a quite complex distributed system with 40 IdPs and 370 SPs.

Intellectual ChallengeThe intellectual challenge is to monitor the «right» thing or control through JMX, toanswer the question: «What is beneficial for Identity Provider and Service Provideradministrators» and how to best integrate it into the Identity Provider component.The project includes conceptual, design and implementation work.

68

B.Project

Plan

69

C.Collected

IdeasforMBeans

70

D. ReportingThis appendix contains the weekly status reports.

Calendar Week 9Work Items done this Week• Kickoff meeting

• Documentation template

• Projectplan

• Virtual machine setup

• Discussion with Chad la Joie concerning code branching

Planned Work Items next Week• Document structure

• Collect ideas for MBeans and some structuring as mind map

• Study research work about similar monitoring

ProblemsNone.

VariaNone.

Attachments• Documentation

71

Calendar Week 10Work Items done this Week• Document structure

• Collect ideas for MBeans and some structuring as mind map

• Study research work about similar monitoring

Planned Work Items next Week• Next Week: reduced work due to SWITCH Shibboleth Installfest

• Study MBeans variants (Types, Notifications etc.)

Problems• Research studies about FIM metrics are rare

Varia• Setup meeting milestone 1 on April 14th at SWITCH

• ISV project thesis

Attachments• Table of contents

• Project plan

• Mindmap

• Research papers

Calendar Week 11Work Items done this Week• Reduced work due to SWITCH Shibboleth Installfest

• Study MBeans variants (Types, Notifications etc.)

• Setup development IdP and SP

• Play around with JConsole, JMX for Jetty and Logback

72

Planned Work Items next Week• Review MBeans by Chad la Joie

• Review MBeans by SWITCH

• Review MBeans by AMAAIS project team

• Discussion integration approach with Chad la Joie

• Continue on further research papers concerning FIM monitoring, Remote Authen-tication Dial-In User Service (RADIUS), MIB etc.

ProblemsNone.

Varia• Setup meeting milestone 1 on April 14th at SWITCH, confirmed

• ISV project thesis, first draft

AttachmentsNone.

Calendar Week 12Work Items done this Week• MBeans reviewed by Chad la Joie→ Good feedback. No missing items in his point

of view.

• MBeans reviewed by SWITCH → Some re-ordering, finer granularity of someMBeans.

• Review of the MBeans by AMAAIS project team initiated → Feedback till 31.3.

• Integration approach discussed with Chad la Joie → Still some open points.

• Further research papers concerning FIM monitoring, RADIUS, MIB etc. consulted→ Not much gain.

73

Planned Work Items next Week• Study MBeans variants (Get, Set, Notification)

• Study MBeans variants (Standard MBeans, Dynamic MBeans, Model MBeansetc.)

• Getting familiar with JMX architecture, standard services, registration etc.

• Process feedback by AMAAIS project.

• Think about best integration approach.

ProblemsSome of the implementation will be more or less complex. Figuring how the proposalfor the implementation should look like. Are there some expectations.

Varia• ISV project thesis, sign and pass to the Master office.

AttachmentsMindmap of the MBeans after review.

Calendar Week 13Work Items done this Week• Documentation: analysis chapter, essence of studying research papers.

• Studied MBeans variants (Get, Set, Notification)

• Studied MBeans variants (Standard MBeans, Dynamic MBeans, Model MBeansetc.)

• Got familiar with JMX architecture, standard services, registration etc.

• Different integration approaches discussed with Chad la Joie.

• First selection of possible implementations discussed.

• Review of the MBeans by AMAAIS project team → some explanations throughthe mailing list → No Feedback!

74

Planned Work Items next Week• Documentation: chapter introduction, analysis evt. concept.

• Design: Advantages/downsides of StandardMBean vs. DynamicMBean.

• Start proposal for implementation.

• Think about design (AOP, Spring framework [22] JMX support, Perf4J [16], . . . )

Calendar Week 14Work Items done this Week• Review of the MBeans by AMAAIS project team → got Feedback.

• Design: Advantages/downsides of StandardMBean vs. DynamicMBean.

• Categorized type of MBeans.

• Thought about design (AOP, Spring framework [22] JMX support, Perf4J [16],. . . )

• Proposal for implementation started.

• Milestone 1 meeting prepared.

Planned Work Items next Week• Documentation: chapter introduction, analysis evt. concept.

• Milestone 1.

• Specification of the MBeans implementation.

• JMX tutorial.

ProblemsNone.

VariaNone.

75

Attachments• Draft of current documentation.

• Slides for milestone 1 meeting.

Calendar Week 15Work Items done this Week• Milestone 1 meeting.

• Specification of the MBeans implementation.

• JMX tutorial (StandardMBean, DynamicMBean, SpringMBean).

• Shibboleth IdP code branch. Setup development environment.

Planned Work Items next Week• Documentation: chapter introduction, concept.

• Revision of chapter analysis after feedback from milestone meeting.

• Implementing first MBean within the IdP.

ProblemsNone.

VariaNone.

AttachmentsNone.

Calendar Week 16Work Items done this Week• Documentation: chapter introduction, concept.

• Revision of chapter analysis after feedback from milestone meeting.

• Implemented first MBean within the IdP (StatusMBean).

76

Planned Work Items next Week• Start implementation MetadataMBean.

• Start implementation SessionMBean.

• Documentation: JMX concepts.

• Documentation: Spring JMX support.

Problems• Decision Shibboleth core team: No integration into Shibboleth IdP 2.x branch.

Gain of this project: Find best implementation approach, collect ideas, have anwell defined integration approach for JMX into Shibboleth IdP 3.x. → Moreflexibility in implementation, input for 3.x branch.

• It seems that not only Shibboleth IdP code has to be adapted, but also Shibbolethcommon and OpenSAML as well.

VariaNone.

AttachmentsCurrent documentation.

Calendar Week 17Work Items done this Week• SessionMBean implemented.

• Ideas for implementation of MetadataMBean.

Planned Work Items next Week• Implementation MetadataMBean.

• Documentation: JMX concepts.

• Documentation: Spring JMX support.

ProblemsNone.

77

VariaNone.


Calendar Week 18Work Items done this Week• Working MetadataMBean implemented.

• Working SessionMBean implemented.

• Working AuthenticationMBean implemented.

• Setup webtest [2] framework and implementation of random login tests.

• Spring AOP tutorial.

• Perf4J [16] tutorial.

Planned Work Items next Week• Finish AOP and Perf4J tutorial.

• Implementation of the PerformanceMBean (Attribute processing and filtering).

• Think about Nagios [13] integration.

• Evt. some documentation.

• Ideas for milestone 2 → Presentation at the next status meeting.

ProblemsNone

VariaNone.


78

Calendar Week 19Work Items done this Week• Done AOP and Perf4J tutorial.

• PerformanceMBean implemented (Attribute processing and filtering).

• Nagios installed, evaluation of a graphical statistics plug-in.

Planned Work Items next Week• Code merge with actual Shibboleth release

• Some first integration into Nagios

ProblemsNone.

VariaNone.

AttachmentsNone.

Calendar Week 20Work Items done this Week• Actual Shibboleth release code merged.

• Usage of the Perf4J Profiler for performance measurements.

• Nagios JMX plug-in evaluation.

Planned Work Items next Week• Setup nagios Status checks.

• Setup first graphs in nagios.

ProblemsAttribute filtering is very fast (cached) → measurements are nearly useless.

79

Varia• Ideas for milestone 2 → Presentation at the next status meeting.

• Demo ideas evt. with Nagios.

AttachmentsScreenshots of Nagios.

Calendar Week 21Work Items done this Week• All status checks and information items integrated into nagios

• All graphs integrated into nagios.

• Nagios JMX plug-in [14] adapted for date values as well as min, max performancedata.

• Reference performance chart using Google’s chart API [3]

Planned Work Items next Week• Configuration into repository.

• Plan demonstration.

• Documentation: Testing

ProblemsNone.

VariaNone.

AttachmentsNone.

80

Calendar Week 22Work Items done this Week• Configuration of integration added into repository.

• Milestone 2 planned. Invitation and program sent.

• Documentation: Concepts

Planned Work Items next Week• Documentation review of structure.

• Slides/Presentation for Milestone 2.

• Test of all demo cases for Milestone 2.

ProblemsNone.

VariaNone.

AttachmentsNone.

Calendar Week 23Work Items done this Week• Preparation Milestone 2 meeting.

• Documentation: Show cases

Planned Work Items next Week• Milestone 2 meeting

• Documentation

ProblemsNone.

81

VariaNone.

AttachmentsNone.

Calendar Week 24Work Items done this Week• Milestone 2 meeting.

Planned Work Items next Week• Documentation

ProblemsNone.

VariaNone.

AttachmentsMilestone 2 presentation.

Calendar Week 25-28Finishing documentation.

82

E. Milestones

Milestone 1Date: April, 14th 2010Place: SWITCH, ZurichAttendees: Thomas Lenggenhager, Patrik Schnellmann,

Andreas Steffen, Halm Reusser

Deliverables• Presentation of collected MBean ideas (metrics & management tasks) reviewed

by Chad la Joie, the AMAAIS project and SWITCH. Current research papersconcerning FIM metrics are respected.

• Specification proposal of MBeans, which will be implemented.

Results• Decision for a set of MBeans for implementation.

ProposalSee 5.1.

TasksRevision of chapter Analysis:Explain transition of the input from the papers to the conclusion and the mind map.Provide traceability of what was new (JMX instead of SNMP monitoring) as well thestructuration and categorization of the metrics and management tasks.

DecisionsThe proposed set of MBeans for implementation was approved.

83

Milestone 2Date: June, 16th 2010Place: SWITCH, ZurichAttendees: Thomas Lenggenhager, Patrik Schnellmann,

Andreas Steffen, Halm Reusser

Deliverables• Live demonstration of the implemented MBeans and their integration into Nagios.

• Conclusion of implementation and integration.

DemonstrationThe demonstration includes some typical usage of the implemented MBeans like query-ing for a specific information, execute management tasks and visualization of statisticaldata.

Different clients (JConsole, HTTP adaptor and Nagios JMX plug-in) are used as well asdifferent visualization methods (JConsole, PNP4Nagios, Google Chart API) and differ-ent notification mechanism (JConsole, Nagios web console and e-mail, LoggingListenerand Logback SMTP appender).

For some demonstration cases, automated random logins are performed using the webtestframework [2], which will be introduced shortly as well.

The following use cases will be demonstrated:

Status Status monitoring, Starttime, Uptime, Version with notification incase of an outage of the directory service.

Sessions Demonstration of administrative logouts. Session monitoring usingWARNING and CRITICAL thresholds as well as visualization.

Metadata Demonstration of forced metadata update. General metadata infor-mation like last refresh, last update, expiration date and require validmetadata (writeable).

Authentication Visualization of successful as well as failed authentications of typeUsernamePassword and PreviousSession. Notification for failed User-namePassword authentication threshold.

Performance Visualization of attribute resolving and filtering performance.

84

Milestone 3Date: July, 16th 2010Attendees: Andreas Steffen, Halm Reusser

Deliverables• Final documentation as printout.

• DVD including virtual machine, documentation, source code, reference materialetc.

85

F. DVDThe following content can be found on the DVD.

binUsed binaries such as the webtest framework [2].

shibboleth-sourcesSources of Shibboleth IdP, Shibboleth Common, OpenSAML, OpenWS and XMLTool-ing.

svn-repThe subversion repository of the project (i.e., the history of the working folder).

tutorialsSeveral tutorials of JMX, Spring [22], AOP and Perf4J [16].

vmThe CentOS virtual machine with installed Shibboleth IdP (JMX enabled), ShibbolethSP and Nagios. The login credentials are root:prima10.

workingThis folder contains all project work divided into the following subfolders:

documentationThe documentation as PDF as well as LATEX sources. The Milestone presentations arefound within the slides folder.

86

implementationThe branched versions of Shibboleth IdP, Shibboleth Common and OpenSAML withthe implemented JMX extensions. The merge, install and deployment scripts. Thebranched and adapted version of the Nagios JMX plug-in.

integrationAll customized configuration of the virtual machine like Apache Directory Server, ApacheHTTPd, Jetty, Shibboleth IdP, Shibboleth SP, Nagios and Nagios plug-ins.

testingThe webtest to simulate parameterized random logins.

87

Date post:	20-Jan-2020
Category:	Documents
Upload:	others
View:	20 times
Download:	0 times

JMX for the Shibboleth Identity...

Documents