MSE Project Thesis
JMX for the Shibboleth Identity Provider
Halm Reusser Advisor: Prof. Dr. Andreas Steffen
July 12, 2010
Hochschule Rapperswil Oberseestrasse 10 CH-8640 Rapperswil Shibboleth is an open source software package for web single sign-on across or within organizational boundaries and is based on the Security Assertion Markup Language (SAML). It is well established and is an important building block of the successful SWITCHaai identity federation.
Therefore the Shibboleth Identity Provider (IdP) is becoming one of the core services at the universities’ Information Technology (IT) departments. They require monitoring and management facilities in order to offer high availability, security and reliability.
Because the Authentication and Authorization Infrastructure (AAI) is the solution to authenticating 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 tasks for 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-down overview. 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 impact on 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 with the 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 6 1.1. Federated Identity Management, SWITCHaai and Shibboleth ...... 6 1.2. JMX ...... 6
2. Analysis 8 2.1. Research ...... 8 2.1.1. Federated Identity Management Metrics ...... 8 2.1.2. Information Assurance Metrics ...... 8 2.1.3. Shibboleth Metrics ...... 9 2.1.4. Authentication Metrics ...... 9 2.1.5. AMAAIS ...... 9 2.1.6. SLA Measurements ...... 9 2.2. Best Current Practices operating a SWITCHaai Identity Provider . . . . 10 2.3. Conclusion: Collection of Metrics and Management Tasks ...... 11
3. Concepts 12 3.1. JMX Concepts ...... 12 3.1.1. JMX Architecture ...... 12 3.1.2. MBeans ...... 13 3.1.3. Standard Agent Services ...... 16 3.1.4. Registering ...... 18 3.2. Spring Framework JMX Support ...... 18 3.2.1. JMX Annotations ...... 18 3.2.2. Naming Strategy ...... 19 3.2.3. Exporting MBeans ...... 20 3.2.4. Notification Listener ...... 20 3.3. Perf4J ...... 21 3.3.1. Profiled Annotation ...... 21
4. Design 23 4.1. Map Metrics and Management Tasks to MBeans ...... 23 4.2. Integration Design ...... 24 4.2.1. Technology Decision ...... 24
5. Implementation 25 5.1. MBean Specification ...... 26
3 5.2. Spring JMX Configuration for the Shibboleth IdP ...... 27 5.2.1. Custom Property Editors ...... 29 5.3. Shibboleth Modules ...... 29 5.4. Perf4J Logback Extensions ...... 30 5.5. MBeans ...... 30 5.5.1. Status Information ...... 30 5.5.2. Session Management ...... 31 5.5.3. Metadata Management ...... 32 5.5.4. Authentication ...... 34 5.5.5. Attribute Processing ...... 37
6. Integration 39 6.1. JMX Monitors ...... 39 6.2. Perf4J and Logback SMTP Appenders ...... 40 6.3. Nagios ...... 42 6.3.1. JMX Plug-in ...... 42 6.3.2. Configuration ...... 42 6.3.3. PNP4Nagios ...... 45
7. Testing 46 7.1. Canoo Webtest ...... 46
8. Use Cases 49 8.1. Clients ...... 49 8.1.1. JConsole ...... 49 8.1.2. HTTP Adaptor ...... 50 8.1.3. Nagios Console ...... 50 8.2. Managed Components ...... 51 8.2.1. Status information ...... 51 8.2.2. Session Management ...... 52 8.2.3. Metadata Management ...... 54 8.2.4. Authentication ...... 55 8.2.5. Attribute Processing Performance ...... 57
9. Conclusion 60 9.1. Implementation ...... 60 9.2. Integration ...... 61 9.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. Introduction
The objective of this project thesis is to collect ideas how the Shibboleth IdP could be enabled 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 FIM metrics 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 monitoring system like Nagios [13].
1.1. Federated Identity Management, SWITCHaai and Shibboleth
Federated Identity Management (FIM) is the management and use of identity informa- tion across security domains, e.g., between individual institutions. It deals with issues such as interoperability, liability, security, privacy and trust.
The SWITCHaai federation [23] is a Shibboleth respectively SAML [19] based federation in Swiss higher education and research, coordinated and led by SWITCH.
Shibboleth [4] is the name of an architecture and an open source software developed by Internet2/MACE (Middleware Architecture Committee for Education). Shibboleth is based on SAML and allows the implementation of a FIM.
1.2. JMX
The JMX defines an architecture for supporting software and network management in the Java programming language. JMX is a unified framework to instrument the disparate pieces of Java code in a modern IT infrastructure. Before JMX, there was no standardized approach in the Java programming language to start, manage, monitor and stop different software components or applications [26].
6 The Java Platform Enterprise Edition (J2EE) is a complex, distributed, service-based enterprise platform. It consists of many different kinds of resources that are dynamically created, distributed, moved across nodes, redeployed and destroyed. The management of such a platform calls for an isolation layer between the management applications and the managed resources. The management architecture must be generic enough to allow the management of a wide variety of different kinds of resources and components. The management architecture must be able to cope with the dynamics and distribution of the platform and provide a management model that allows increasingly long uptimes and 24x7 service. JMX can provide all this [26].
7 2. Analysis
In this chapter FIM metrics and management tasks are analyzed. The main objective of the situation analysis is to gain an overview of possible MBeans for the Shibboleth IdP.
2.1. Research
The first step is to collect and compare ideas with research papers concerning similar fields 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 Metrics The 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 are identified, which are grouped into three categories: Identity provider metrics Metrics like accounts, groups, authentication claims and authorization 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 the collection. As the Shibboleth IdP is neither a provisioning system nor has support for that, there is no gain from that aspect of the article. Furthermore, the article discusses the benefits of having well defined metrics in the context of risk management, service predictions and real time decision-making.
2.1.2. Information Assurance Metrics The paper Information Assurance in Federated Identity Management [24] investigated two well-known federated identity management solutions, Microsoft Passport and Liberty Alliance, attempting to identify Information Assurance requirements in FIM. One of the goals was to measure the performance focusing on authentication. The developed metrics are mostly in the context of performance like data access time, message processing time, authentication time, SSO time etc.
8 2.1.3. Shibboleth Metrics SWITCH logs all service accesses within the SWITCHaai federation, which pass through the central Discovery Service. For reporting purposes, the tool WAYFalyzer exists. The WAYFalyzer allows to aggregate accesses to IdPs or Service Providers (SPs) over arbi- trary time periods with different sampling rates. The functionalities of the WAYFalyzer are 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 Metrics Under the term of authentication metrics a lot of research work was done in the field of trusted intermediate paths [30, 31]. This is not an issue within common Shibboleth federations due to trusted Metadata.
LDAP Metrics There are published LDAP metrics of the North Carolina State University [9]. They measure indicators like binds, unbinds, successful and failed connections, searches and other typical LDAP operations. The level of granularity is on client addresses or total counts.
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 two aspects of the system. The first is very similar to the above-mentioned LDAP metrics i.e., measure typical LDAP operations. The second type of measurements is related with the performance of SSO request processing, but the implementation is on a very general level like Hypertext Transfer Protocol (HTTP) server process usage, connections, servlet response time as well as load and number of current session.
2.1.5. AMAAIS The 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 a Shibboleth-based AAI. The AMAAIS project team reviewed the metrics assessed, ap- proved them and found no critical missing metrics.
2.1.6. SLA Measurements SLA metrics are used to measure performance characteristics of the service objects. They are retrieved directly from the managed resource, middleware or instrumented applications.
9 Several studies about SLA metrics were consulted, e.g., IP-Oriented Operations and Management [27], A Categorization Scheme for SLA Metrics [28] or SLA management in 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 SWITCHaai Identity Provider
The SWITCHaai team — together with the SWITCHaai community — published a paper called BEST CURRENT PRACTICES for operating a SWITCHaai Identity Provider [32]. Thanks to those requirements and suggestions, possible ideas for MBeans could be extracted.
10 2.3. Conclusion: Collection of Metrics and Management Tasks
While studying the research papers and other resources, many generic metrics (MBean measurements) 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 JMX implementation have not been found. It seems that this relatively new technology and approach — to hook directly into Java applications and monitor and manage individual components — 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 well as 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, authentications etc. 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. Concepts
The chapter “Concepts” introduces the used concepts, technologies, frameworks and libraries such as JMX, Spring [22] and Perf4J [16].
3.1. JMX Concepts
In this section the main architecture and concepts of the JMX are explained.
3.1.1. JMX Architecture Figure 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. It is 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 and adaptors. A connector provides full remote access to the MBeanServer Application Programming Interface (API) using various communication frameworks as Remote Method Invoca- tion (RMI) etc., while an adaptor adapts the API to another protocol (SNMP, . . . ) or to a web-based user interface.
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 of JMX connectors and protocol adapters. Connectors are used to connect an agent with a remote JMX-enabled management application. This form of communication involves a connector in the JMX agent and a connector client in the management application.
3.1.2. MBeans The 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 HumanMBean setName(name:String) getName():String setAge(age:int) getAge():int sayHello()
Human name:String age:int setName(name:String) getName():String setAge(age:int) getAge():int sayHello()
Figure 3.2.: Standard MBean
The advantages of Standard MBeans are that those are simple to understand and implement. The disadvantage is that a new interface has to be specified and implemented which might break existing APIs. Dynamic MBeans Implement the javax.management.DynamicMBean interface which provides a way to list the attributes and operations, and to get and set the attribute values.
DynamicMBean getMBeanInfo():MBeanInfo getAttribute(attribute:String):Object getAttributes(attributes:String[]):AttributeList setAttribute(Attribute attribute) setAttributes(AttributeList attributes):AttributeList Object 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., at run-time. The methods described in the interface (see Figure 3.3) are generic and detyped. Therefore some extra discipline is required in order to implement Dynamic MBeans. The generic definition of the Dy- namic MBean interface provides increased flexibility but should be handled 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 makes use 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 must implement its own corresponding MBean (Standard MBean) or the DynamicMBean interface. Attributes Management attributes are named characteristics of an MBean. There are three kinds of attributes, read-only, write-only and read-write attributes. Attributes can be of any valid Java type. Operations Management operations include all methods declared within the MBean. Management operations can have return values. The arguments as well as the return value can be of any valid Java type. An operation may throw any type of exceptions. Notifications The JMX notifications are based on the Java event mechanism and used for events and state changes. An MBean broadcasting management events must implement the NotificationBroadcaster interface. A NotificationListener can subscribe and unsubscribe to a NotificationBroadcaster. It is possible using the NotificationFilter to only get a spe- cific type of Notification. Defined notification types are AttributeChangeNotification or ThresholdExceededNotification for instance. Custom im- plementations are possible. Object name Represents the object name of an MBean, or a pattern that can match the names of several MBeans [7]. It is used for registering and lookup MBeans in the registry. An object name consists of two parts, the domain and the key properties. The domain is a string of characters not including the character colon (:). The key 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 as the determination of it is different in Standard respectively Dynamic MBeans.
15 3.1.3. Standard Agent Services The Standard agent services MBeans are just an architectural distinction to resource MBeans. 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 and can be used to schedule notifications to occur at a given date and time or at defined intervals. The JMX timer service is a similar service like the cron service on Unix systems. Monitor service The monitor service can be used to monitor the attributes of managed resources. Monitors can be utilized to provide notifications about attribute changes, threshold overstepping etc. The monitor service is examined carefully in section 3.1.3. M-Let service The M-Let service is a mechanism to dynamically load new Java classes to the MBean server. In addition, the M-Let service allows the 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 act like 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 that are either integer or floating point types and arbitrarily increase or decrease. String monitor The string monitor can be used to monitor attributes of the String type 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 be sent to the interested listeners. When the observed attribute’s value increases to match or exceed the threshold a notification is sent. The offset is added to the threshold as many times as it is necessary for the threshold value to become greater than the current observed attribute value. However, only one notification is ever sent, no matter how many times the offset must be added to the threshold value [26]. The behavior of the counter 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. Registering Listing 3.1 illustrates how to retrieve the platform’s MBeanServer. c l a s s java . lang .management.ManagementFactory { s t a t i c MBeanServer getPlatformMBeanServer() {...} } Listing 3.1: Retrieving the MBeanServer of the Platform After the MBeanServer is available it can be used to register an MBean implementation using a given ObjectName. See Listing 3.2.
MBeanServer server = ManagementFactory.getPlatformMBeanServer (); ObjectName name = new ObjectName( "org.example.jmx:name=Foo" ); FooMBean foo = new Foo ( ) ; server .registerMBean(foo , name); Listing 3.2: Register an MBean
3.2. Spring Framework JMX Support
The 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 integrate a 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 Annotations An 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 and packages may be annotated. Unlike Javadoc tags, Java annotations can be reflective in that they can be embedded in class files generated by the compiler and may be retained by the Java Virtual Machine (JVM) to be made retrievable at run-time.
To enable the use of annotations for the management interface definition, Spring provides a set of annotations that mirror the commons attribute classes and an implementation of the JmxAttributeSource strategy interface, the AnnotationsJmxAttributeSource class, that allows the MBeanInfoAssembler to read them. Listing 3.3 shows a bean where the management interface is defined by the presence of annotation types.
18 @ManagedResource(objectName="org.example:type=Human,name=Me" ) @ManagedNotification(name="AgeChangeNotification" , notificationTypes={"AgeChange" }) public class Human implements NotificationPublisherAware {
p r i v a t e String name; p r i v a t e i n t age ; p r i v a t e NotificationPublisher publisher;
p u b l i c Human(String name, i n t age ) { t h i s .name = name; t h i s . age = age ; }
@ManagedAttribute(description="The name attribute" ) p u b l i c String getName() { r e t u r n name ; }
@ManagedAttribute(description="The age attribute" ) p u b l i c i n t getAge ( ) { r e t u r n age ; }
@ManagedAttribute(description="The age attribute" ) p u b l i c v o i d setAge ( i n t age ) { t h i s . age = age ; publisher.sendNotification( new Notification( "AgeChange" , t h i s , 0, sayHello())); }
@ManagedOperation( description="Returns the humans name and age" ) p u b l i c String sayHello() { r e t u r n "I’m " + name + "," + age + " years old " ; }
@ManagedOperation( description="Introduce itself to another" ) @ManagedOperationParameter(name = " name " , description = "The name of the other" ) p u b l i c String introduceYourself(String name) { r e t u r n " Hello " + name + "!" + sayHello(); }
p u b l i c v o i d setNotificationPublisher(NotificationPublisher publisher) { t h i s .publisher = publisher; }
} Listing 3.3: Spring JMX Annotations
3.2.2. Naming Strategy Spring supports different naming strategies or presents other ways of controlling object names. 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 for an example. Metadata naming Uses the objectName property of the ManagedResource attribute on 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
3.2.4. Notification Listener How 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 is needed. A simple LoggingNotificationListener might look like in Listing 3.5.
public class LoggingNotificationListener implements NotificationListener , NotificationFilter {
private final Logger log = LoggerFactory.getLogger(getClass ());
p u b l i c v o i d handleNotification(Notification notification , Object handback) { l o g . e r r o r ( "\n*** Notification ***\n{}\n*** Notification ***" , notification); }
public boolean isNotificationEnabled(Notification notification) { r e t u r n t r u e ; }
} Listing 3.5: LoggingNotificationListener The MBeanExporter allows to define a NotificationListener mapping. The Listing 3.6 defines that every published notification is sent to the LoggingNotificationListener.
20 Listing 3.6: NotificationListener Mapping
3.3. Perf4J
Perf4J [16] is a set of utilities for calculating and displaying performance statistics for Java code. It is integrated with the most common logging frameworks.
It provides aggregated performance statistics like mean, minimum, maximum, standard deviation and transactions per second over a set time span. The main reason to use the Perf4j library is the ability to expose those performance statistics as JMX attributes and to send notifications when statistics exceed specified thresholds.
3.3.1. Profiled Annotation Perf4J 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 method call. The logger parameter indicates to which appender the performance statistics are sent.
@Profiled(tag="execution" , l o g g e r="logger.service" ) p u b l i c v o i d s e r v i c e ( long m i l l i s ) { logger.info( "Run service for {} millis" , m i l l i s ) ; t r y { Thread.sleep(millis ); } catch (InterruptedException e) {} } Listing 3.7: Profiled Annotation Listing 3.8 shows the logging configuration with the specific appenders.
21
Performance Statistics 2010-06-04 18:25:40 - 2010-06-04 18:25:50 Tag Avg(ms) Min Max Std Dev Count execution 3403.0 3403 3403 0.0 1
Performance Statistics 2010-06-04 18:25:50 - 2010-06-04 18:26:00 Tag Avg(ms) Min Max Std Dev Count execution 4201.7 3464 4623 523.4 3
Performance Statistics 2010-06-04 18:26:00 - 2010-06-04 18:26:10 Tag Avg(ms) Min Max Std Dev Count execution 4058.5 3784 4333 274.5 2
Instead of output those performance statistics, Perf4J provides other appenders such as 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. Design
This chapter discusses the aspects of how to map the collected metrics and management tasks 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 MBeans
It is important to order and classify the collected ideas into specific type of MBeans which have structural similarities.
Metrics In the field of metrics there are the types information, frequency1 and time measure with the characteristics listed in Table 4.1.
arbitrary readable attribute Information String- or CounterMonitor with adequate thresholds. counter attribute (integer) Frequency CounterMonitor in DifferenceMode with adequate granularity and thresholds. counter attribute (integer) of process calls Time measure counter attribute (long) of process times Last info (count, start, end, duration).
Table 4.1.: Mapped Type of Metrics to MBeans
1Events per time unit
23 Management Tasks In the field of management tasks there are the types configuration and management tasks with the characteristics listed in Table 4.2.
Configuration arbitrary writable attribute. arbitrary method calls with Management tasks arbitrary return type and argument type(s).
Table 4.2.: Mapped Type of Management Tasks to MBeans
4.2. Integration Design
The design of the MBean integration into the Shibboleth IdP respects SUN’s JMX best practices [8].
4.2.1. Technology Decision Due 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 it becomes clear that it should be feasible almost without any drawbacks.
Perf4J is a very convenient profiling library. The supplementary support for exposing performance data as JMX attributes in MBeans justifies its choice.
24 5. Implementation
After collecting some ideas, studying available concepts and mapping the ideas to a specific type of MBean, the objective is to provide a reference implementation fulfilling the 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. MBean Specification
Context Features Complexity count active sessions readable attribute get list of users with session readable attribute Operations Sessions Medium 2 destroy session for user operation with 1 argument destroy all sessions operation Expose for each MDProviderID: requires DynamicMBean reload metadata operation Operations Metadata get last reload timestamp operation with return value Complex 3 set/get maintain expired metadata read- and writable attribute send notification in case of change notification readable attribute IdP uptime get uptime
26 Reliability readable attribute with String Simple 1 IdP status get simple status (OK, NOK) monitor (alerts) Expose for each login handler: requires DynamicMBean Accounting Authentications Medium 2 count of authentication counter monitor requires DynamicMBean Failed au- Expose for each login handler: Security counter monitor with threshold Simple 1 thentications count of failed authentications notifications (alerts) Attribute processing time for attribute resolving Performance time measure with monitor Complex 3 processing & filtering
Table 5.1.: MBean Specification 5.2. Spring JMX Configuration for the Shibboleth IdP
The Spring JMX beans and configuration items are defined for clarity purposes in a separate file internal-jmx.xml, which is included by the IdPs main application context internal.xml. See Listing 5.1.
• 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).
15
27
40
28 90
105 Listing 5.2: internal-jmx.xml
5.2.1. Custom Property Editors Spring provides a set of property editors which are used to convert from String values to object values such as Integer, Date etc. This is a very convenient feature. Some types 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 editor by extending the PropertyEditorSupport class. Because the type ObjectName is often used 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 Modules
The Shibboleth IdP consists of three main software components. Table 5.2 indicates which software versions are branched.
29 Branched Component Description version Shibboleth Identity Provider The Shibboleth Identity Provider is used 2.2.0 (r2933) by an organization to securely assert in- formation, via SAML, about their users. Shibboleth Common Library The Shibboleth Common Library provides 1.2.0 (r900) services/infrastructure that is common between Identity and Service providers. OpenSAML-J The OpenSAML-J library provides tools 2.4.0 (r1467) to support developers working with the Security Assertion Markup Language (SAML).
Table 5.2.: Shibboleth Component Versions
5.4. Perf4J Logback Extensions
The Perf4J library uses existing logging frameworks for publishing performance data to several 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 the support for Logback is non-yet released. Although it is on the roadmap I decided to implement the Logback support in the meantime by myself.
The classes AsyncCoalescingStatisticsAppender, GraphingStatisticsAppender and JmxAttributeStatisticsAppender of Perf4J was Logback-enabled and can be found on the DVD. See Appendix F.
5.5. MBeans
This section contains all implemented MBeans. The most important design ideas and code level changes are described.
5.5.1. Status Information So 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" , description="Status information of the Identity Provider" ) public class StatusServlet extends HttpServlet { ... private static final short OK = 0 ; private static final short WARNING = 1 ; private static final short CRITICAL = 2; ... p u b l i c v o i d init(ServletConfig config) throws ServletException { ... // JMX self registration WebApplicationContext context = WebApplicationContextUtils .getWebApplicationContext(getServletContext ()); MBeanExporter exporter = (MBeanExporter) context.getBean( " exporter " ); exporter . setEnsureUniqueRuntimeObjectNames( f a l s e ); exporter .registerManagedResource( t h i s ); } ...
@ManagedAttribute(description="Start date/time of the Identity Provider" ) p u b l i c Date getStarttime() { r e t u r n startTime.toDate(); }
@ManagedAttribute(description="Uptime of the Identity Provider in seconds" ) p u b l i c long getUptime() { DateTime now = new DateTime(ISOChronology . getInstanceUTC ()); r e t u r n now.minus(startTime.getMillis ()). getMillis() / 1000; }
@ManagedAttribute(description="The status code of the Identity Provider" ) public short getStatuscode() { t r y { attributeResolver.validate (); r e t u r n OK; } catch (AttributeResolutionException e) { r e t u r n CRITICAL; } }
@ManagedAttribute(description="The status code of the Identity Provider" ) p u b l i c String getStatus() { s w i t c h (getStatuscode()) { 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" ; }
@ManagedAttribute(description="Version of the Identity Provider" ) p u b l i c String getVersion() { r e t u r n V e r s i o n . c l a s s .getPackage(). getImplementationVersion (); } } Listing 5.3: StatusMBean
5.5.2. Session Management Listing 5.4 illustrates the extension of the SessionManagerImpl component to provide the required JMX functionalities.
31 The main addition and changes are the introduction of a session counter and the getSessions() and destroySessions() operations.
@ManagedResource(objectName="mseproject:type=Management,name=Session" , description="Session management of the Identity Provider" ) public class SessionManagerImpl implements SessionManager
...
@ManagedOperation( description="Destroy a session" ) @ManagedOperationParameter(name="sessionID" , description="The sessionID" ) p u b l i c v o i d destroySession(String sessionID) { // already implemented method }
@ManagedAttribute(description="Current sessions" ) p u b l i c Map
@ManagedAttribute(description="Count of current sessions" ) p u b l i c i n t getCount() { r e t u r n sessionCount ; }
@ManagedOperation( description="Destroy current sessions" ) p u b l i c i n t destroySessions() { i n t count = sessionCount; f o r (String sessionID : getSessions().keySet()) destroySession(sessionID ); r e t u r n count ; } } Listing 5.4: SessionMBean
5.5.3. Metadata Management For 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 methods have to be overridden.
@ManagedResource @ManagedNotification(name="MetadataChangeNotification" , notificationTypes={"MetadataChange" }, description="Sends a notification if metadata were changed" ) public class ResourceBackedMetadataProvider extends AbstractReloadingMetadataProvider implements NotificationPublisherAware {
32 ...
@ManagedAttribute(description="Last refresh of the metadata" ) p u b l i c Date getLastRefreshDate() { return super .getLastRefresh ().toDate(); }
@ManagedAttribute(description="Last update of the metadata" ) p u b l i c Date getLastUpdateDate() { return super .getLastUpdate ().toDate(); }
@ManagedAttribute(description="Expiration date of the metadata" ) p u b l i c Date getExpirationDate() { return super .getExpirationTime ().toDate(); }
@ManagedOperation( description="Refresh the metadata" ) p u b l i c v o i d r e f r e s h ( ) throws MetadataProviderException { super .refresh(); }
@ManagedAttribute(description="Require valid metadata" ) public boolean getRequireValidMetadata() { return super .requireValidMetadata (); }
@ManagedAttribute(description="Require valid metadata" ) p u b l i c v o i d setRequireValidMetadata( boolean r e q u i r e ) { super .setRequireValidMetadata(require ); }
p u b l i c v o i d emitChangeEvent() { super .emitChangeEvent (); i f (notificationPublisher != n u l l ) notificationPublisher .sendNotification( new Notification( "MetadataChange" , t h i s , 0, getMetadataIdentifier() + " reloaded " )); } } Listing 5.5: ResourceBackedMetadataProvider Listing 5.6 illustrates how all metadata providers of type ResourceBackedMetadataProvider are registered as MBeans. For identification of the MBean the objectName is dynamically defined using the metadata identifier (e.g., the filename).
public class SAMLMDRelyingPartyConfigurationManager extends BaseReloadableService implements RelyingPartyConfigurationManager {
private void registerResourceBackedMetadataProviderMBeans(MBeanExporter exporter) { ChainingMetadataProvider chainingMetadataProvider ; t r y { chainingMetadataProvider = (ChainingMetadataProvider) getMetadataProvider (); } catch (ClassCastException e) { l o g . e r r o r ( "Sorry, assuming ChainingMetadataProvider" ); r e t u r n ; }
f o r (MetadataProvider metadataProvider : chainingMetadataProvider.getProviders()) { ResourceBackedMetadataProvider provider ; t r y { provider = (ResourceBackedMetadataProvider) metadataProvider;
33 } catch (ClassCastException e) { l o g . warn ( "Sorry, {} not supported, yet" , metadataProvider.getClass ()); c o n t i n u e ; }
ObjectName objectName = n u l l ; t r y { objectName = new ObjectName( "mseproject:type=Metadata,name="+provider.getMetadataIdentifier ()); } catch (MalformedObjectNameException e) { l o g . e r r o r ( "{}" , e ) ; } exporter .registerManagedResource(provider , objectName); } }
...
protected void onNewContextCreated(ApplicationContext newServiceContext) throws ServiceException { ... MBeanExporter exporter = (MBeanExporter) newServiceContext.getBean( " exporter " ); exporter . setRegistrationBehavior (MBeanExporter .REGISTRATION_REPLACE_EXISTING); registerResourceBackedMetadataProviderMBeans(exporter ); } } Listing 5.6: SAMLMDRelyingPartyConfigurationManager
5.5.4. Authentication The 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 required JMX functionalities and be independent of a specific LoginHandler the introduction of a generic AuthenticationMBean was necessary.
Figure 5.1 illustrates the relations between the LoginHandlers and the AuthenticationMBean. The interface LoginHandler contains methods for managing login counts of different results (i.e., successful, failed). The AbstractLoginHandler provides implementations for those methods as well as other convenient operations like increment etc., which are used by the concrete classes (e.g., PreviousSessionLoginHandler and UsernamePasswordLoginHandler) then.
Each AuthenticationMBean knows its LoginHandler in an association relationship and contains the @ManagedAttribute annotations for getting the count of successful and failed authentications as well the @ManagedOperation annotations for resetting the coun- ters.
34 AuthenticationMBean <
AbstractLoginHandler loginCount: ConcurrentMap
PreviousSessionLoginHandler UsernamePasswordLoginHandler
Figure 5.1.: AuthenticationMBean
Listing 5.7 shows the registration of a AuthenticationMBean for each configured LoginHandler. The objectName is created dynamically by the LoginHandler’s class name.
public class AuthenticationEngine extends HttpServlet {
p u b l i c v o i d init(ServletConfig config) throws ServletException { ... registerAuthenticationMBeans (); }
...
private void registerAuthenticationMBeans() { WebApplicationContext context = WebApplicationContextUtils .getWebApplicationContext(getServletContext ()); MBeanExporter exporter = (MBeanExporter) context.getBean( " exporter " ); f o r (LoginHandler loginHandler : handlerManager.getLoginHandlers().values()) { AuthenticationMBean mbean = new AuthenticationMBean(loginHandler ); ObjectName objectName = n u l l ; t r y { objectName = new ObjectName( "mseproject:type=Authentication,name=" +loginHandler . getClass ().getSimpleName()); } catch (MalformedObjectNameException e) { LOG . e r r o r ( "{}" , e ) ; } exporter .registerManagedResource(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 authentication was successful, it has to delegate the task to the UsernamePasswordLoginServlet. See Listing 5.8.
public class UsernamePasswordLoginHandler extends AbstractLoginHandler { ... p u b l i c v o i d l o g i n ( f i n a l HttpServletRequest httpRequest , f i n a l HttpServletResponse httpResponse) { ... httpRequest.getSession (). setAttribute( t h i s . getClass ().getName(), t h i s ); ... httpResponse. sendRedirect(authenticationServletURL ); } } Listing 5.8: UsernamePasswordLoginHandler Listing 5.9 describes how the UsernamePasswordLoginServlet increments the respec- tive counter for successful or failed authentications.
public class UsernamePasswordLoginServlet extends HttpServlet { ... protected void service(HttpServletRequest request , HttpServletResponse response) throws ServletException , ... UsernamePasswordLoginHandler loginHandler = (UsernamePasswordLoginHandler) request . getSession (). getAttribute(UsernamePasswordLoginHandler. c l a s s .getName()); t r y { authenticateUser(request , username , password); loginHandler . incrementLoginCount(LoginHandler .LOGIN_RESULT_SUCCESS); AuthenticationEngine.returnToAuthenticationEngine(request , response ); } catch (LoginException e) { request. setAttribute(failureParam , " true " ); r e q u e s t . s e t A t t r i b u t e ( L o g i n H a n d l e r . AUTHENTICATION_EXCEPTION_KEY, new AuthenticationException(e)); loginHandler . incrementLoginCount(LoginHandler .LOGIN_RESULT_FAIL); redirectToLoginPage(request , response); } } ... } Listing 5.9: UsernamePasswordLoginServlet
PreviousSessionLoginHandler This section contains the enablement of the PreviousSessionLoginHandler as MBean.
In contrary to the UsernamePasswordLoginHandler the PreviousSessionLoginHandler is able to decide if an authentication was successful or not. Listing 5.10 illustrates the implementation.
36 public class PreviousSessionLoginHandler extends AbstractLoginHandler { ... p u b l i c v o i d login(HttpServletRequest httpRequest , HttpServletResponse httpResponse) { ... Session idpSession = (Session) httpRequest.getAttribute( S e s s i o n . HTTP_SESSION_BINDING_ATTRIBUTE ) ; i f (idpSession == n u l l ){ l o g . warn ( "No existing IdP session available." ); h t t p R e q u e s t . s e t A t t r i b u t e ( L o g i n H a n d l e r . AUTHENTICATION_ERROR_KEY, "No existing IdP session available" ); incrementLoginCount(LoginHandler .LOGIN_RESULT_FAIL); } e l s e { l o g . debug ( "Using existing IdP session for {}" , idpSession.getPrincipalName()); httpRequest . setAttribute (LoginHandler .PRINCIPAL_NAME_KEY, idpSession .getPrincipalName ()); i n c r e m e n t L o g i n C o u n t ( L o g i n H a n d l e r . LOGIN_RESULT_SUCCESS ) ; } AuthenticationEngine.returnToAuthenticationEngine(httpRequest , httpResponse); } ... } Listing 5.10: PreviousSessionLoginHandler
5.5.5. Attribute Processing This section touches the performance MBean, which provides statistics about attribute processing. 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.
public class ShibbolethAttributeResolver extends BaseReloadableService implements AttributeResolver
@Profiled(tag="attributes.resolve" , l o g g e r="mseproject.attributeprocessing" ) p u b l i c Map
}
public class ShibbolethAttributeFilteringEngine extends BaseReloadableService implements AttributeFilteringEngine
@Profiled(tag="attributes.filter" , l o g g e r="mseproject.attributeprocessing" ) p u b l i c Map
37 For exposing the performance data in an MBean the logger mseproject.attributeprocessing has to supplemented by a JMX appender. See Sec- tion 6.2.
38 6. Integration
This chapter documents the integration of the new features provided by the JMX enabled IdP into the monitoring system Nagios.
6.1. JMX Monitors
Listing 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 the status of the IdP and publishes notification in case of a failure.
For each AuthenticationMBean a monitor configured in DifferenceMode provides the rate 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.
9
19
39 34
39
Listing 6.1: internal-jmx-monitor.xml
6.2. Perf4J and Logback SMTP Appenders
Listing 6.2 illustrates one part of the Logback configuration. There are several appenders and 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 EMAIL appender.
For the Perf4J configuration following loggers and appenders are defined:
JMX This appender exposes performance statistics as attributes to a JMX MBean. In addition it allows you to set thresholds for these statistics and send notifications when the logged values exceed the thresholds. Graph The GraphingStatisticsAppender uses the GroupedTimingStatistics to generate performance graphs. These graphs, which are implemented as URLs using the Google Chart API to create the actual graph images, can be displayed in a browser.
40 AttributeProcessing The logger which upstreams the Perf4J performance data to the JMX and the graph appender.
3
23
33
41 63
68
6.3. Nagios
Nagios is a powerful monitoring system and provides an extensible plug-in concept. For this integration a JMX Nagios plug-in [14] was utilized and customized.
6.3.1. JMX Plug-in The 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 OK 1 WARNING 2 CRITICAL 3 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. Configuration Listing 6.3 illustrates the definition of the used JMX plug-in commands. For most service monitoring 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.
# Further command definitions omitted
define command { command_name check_idp command_line /opt/nagios −jmx−plugin/check_jmx \ −U service:jmx:rmi:///jndi/rmi://localhost:1099/jmx \
42 −O mseproject : type=$ARG1$,name=$ARG2$ −A $ARG3$ $ARG4$ }
define command { command_name check_idp_authentications command_line /opt/nagios −jmx−plugin/check_authentications \ −U service:jmx:rmi:///jndi/rmi://localhost:1099/jmx \ −O mseproject : type=Authentication ,name=$ARG1$ $ARG2$ }
define command { command_name check_idp_attributeprocessing command_line /opt/nagios −jmx−plugin/check_attributeprocessing \ −U service:jmx:rmi:///jndi/rmi://localhost:1099/jmx \ −O mseproject :type=Performance ,name=AttributeProcessing } Listing 6.3: commands.cfg check_idp Listing 6.4 demonstrates the usage of the Nagios JMX plug-in check_idp command. It is possible to query an arbitrary attribute of an MBean and optionally specify thresholds for warning and critical values.
# /opt/nagios −jmx−plugin/check_jmx \ −U service:jmx:rmi:///jndi/rmi://localhost:1099/jmx \ −O mseproject: type=Management ,name=Session \ −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 multiple performance outputs. In this case for successful as well failed authentications.
# /opt/nagios −jmx−plugin/check_idp_authentications \ −U service:jmx:rmi:///jndi/rmi://localhost:1099/jmx \ −O mseproject: type=Authentication ,name=UsernamePassword −w 3 −c 5 Listing 6.5: check_idp_authentications The output might look like:
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/max values to the performance output.
# /opt/nagios −jmx−plugin/check_idp_attributeprocessing \ −U service:jmx:rmi:///jndi/rmi://localhost:1099/jmx \ −O mseproject: type=Performance ,name=AttributeProcessing Listing 6.6: check_idp_attributeprocessing The output might look like:
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 makes use of the previously defined commands.
# Further host and service group definitions omitted
define service { name abstract −jmx−s e r v i c e host_name idp.example.org servicegroups IdP
max_check_attempts 1 check_interval 60 check_period 24x7
contacts reusser notification_period 24x7 notification_interval 0
process_perf_data 0 }
define service { name graph process_perf_data 1 action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$ }
define service { use a b s t r a c t −jmx−s e r v i c e service_description status check_command check_idp!Information!Status!Status −w @WARNING −c @CRITICAL }
define service { use graph, abstract −jmx−s e r v i c e service_description sessions check_command check_idp!Management!Session!Count! −w 50 −c 100 }
define service { use graph , abstract −jmx−s e r v i c e service_description authentications −username−password check_command check_idp_authentications!UsernamePassword! −w 3 −c 5 }
define service { use a b s t r a c t −jmx−s e r v i c e
44 service_description idp −metadata−e x p i r e check_command check_idp!Metadata!\ /etc/shibboleth/sp−metadata.xml!ExpirationDate } define service { use graph , abstract −jmx−s e r v i c e service_description attributeprocessing check_command check_idp_attributeprocessing }
# service definitions omitted Listing 6.7: idp.example.org.cfg
6.3.3. PNP4Nagios PNP4Nagios [17] is a plug-in for Nagios which allows to visualize performance data using RRD graphs [18]. Via a template based system it is possible to customize style, labels and resolution of the graphs. The custom templates which configure the rrdgraph are found on the DVD (Appendix F). See Section 8 for example graphs.
45 7. Testing
For testing the counter or performance MBeans one needs to simulate IdP logins. The following authentication types are distinguished:
Successful authentication A user — without any SSO session — authenticates successfully at the IdP using valid credentials (e.g., username and password). Failed authentication A user — without any SSO session — authenticates unsuccessfully at the IdP using invalid credentials (e.g., wrong password). Previous session authentication A user — with a valid SSO session — authenticates successfully 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 a random account per login.
7.1. Canoo Webtest
Canoo’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 next iteration (Line 47).
4
49 Listing 7.1: Shibboleth Login Test Listing 7.2 illustrates how such a test can be parameterized. The explanation of each configuration option is inline within this properties file.
47 webtest .home=/Users/reusser/MSE/Projekt/bin/webtest 2 sp. url=https://sp.example.org/Shibboleth .sso/Logout?return=https://sp.example.org/test/ sp. title=Shibboleth Attributes
# Check for an user attribute sp. [email protected] 7 # IdP login page idp. title=Shibboleth Identity Provider − Login idp . usernamefield=j_username idp . passwordfield=j_password 12 idp.authnFailed=Authentication Failed idp . loginbutton=Login
# Random logins between from and to # Only one login: from=0, to=1 17 # Exact 5 logins: from=5, to=6 repeat .from=500 repeat . to=100001
# Random login delays between from and to 22 # No delay: from=0, to=1 # Exact 5 seconds: from=5, to=6 delay .from=0 delay .to=60
27 # Random user choice # If only one user =student1 username.random=student1 ,student2 , staff1 , staff2 ,alum1
# Only valid logins =password 32 # 3/4 valid logins , 1/4 invalid logins =password,password,password,wrong password.random=password ,password ,password ,password ,password ,password ,password ,wrong password. valid=password
# Only forceAuthn =true 37 # 3/4 forceAuhtn , 1/4 previousSession =true ,true ,true ,false logout.random=true ,true ,true , false Listing 7.2: Test Configuration Due to this flexible webtest it is easy to provide various simulations for testing the counter or performance MBeans.
48 8. Use Cases
This chapter shows some of the use cases for the implemented MBeans as well as their integration into the Nagios monitoring system.
8.1. Clients
All managed attributes and managed operations are accessible by the JConsole or the HTTP adaptor (i.e., all attributes can be read, writable attributes can be set, operations could be executed — with any arguments — and return values might be examined).
8.1.1. JConsole The easiest way to monitor and manage MBeans is the usage of the JConsole, which is distributed with the Java Runtime Environment (JRE). Figure 8.1 shows the usage of the 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 subscribing to the corresponding notification(s).
8.1.2. HTTP Adaptor Figure 8.2 illustrates the HTML view of an MBean provided by the HTTP adaptor.
Figure 8.2.: HTTP Adaptor
8.1.3. Nagios Console For all attributes observed by Nagios (one minute frequency) an e-mail is sent if a WARNING or CRITICAL threshold is configured and reached.
50 8.2. Managed Components
This section shows for each implemented MBean its managed attributes and operations, its monitors and notifications if available as well as provided statistic graphs and a demonstration case.
8.2.1. Status information The following MBean provides the status information of the IdP: objectName="mseproject:type=Information,name=Status"
Managed Attributes Attribute Description r/w Starttime Start date and time of the IdP r Uptime Uptime in seconds of the IdP r Status Status of the IdP (OK|WARNING|CRITICAL) r Statuscode Statuscode OK=0, WARNING=1, CRITICAL=2 r Version IdP version r
Monitors & Notifications The mseproject:type=Information,name=StatusMonitor MBean checks every minute the 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 WARNING or CRITICAL state the color changes to orange respectively red. According to the Nagios notification 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 service unavailable (Listing 8.1).
51 # service apacheds stop 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 16:07:03 +0200 From: nagios
∗∗∗∗∗ Nagios ∗∗∗∗∗
Notification Type: PROBLEM
Service: status Host: Shibboleth Identity Provider Address: idp.example.org State: CRITICAL Listing 8.2: Nagios Problem Alert E-mail
8.2.2. Session Management The IdP sessions are managed by the following MBean: objectName="mseproject:type=Management,name=Session"
Managed Attributes Attribute Description r/w Count Current number of sessions r Sessions List of current sessionIDs with associated principal r
Managed Operations Operation Parameter Return value destroySession sessionID destroySessions number of destroyed sessions
52 Monitors & Notifications Nagios checks every minute the current count of valid user sessions at the IdP. It is configured 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 the session count over 4 hours. The orange respectively the red lines indicate the WARNING and CRITICAL thresholds.
Figure 8.6.: IdP Sessions
Demonstration Nagios as well as the graphs might be used to observe the current number of active sessions.
Figure 8.7.: Number of IdP Sessions
Another example might be an administrative logout. If the user student1 executes a login, 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 the session of student1 is listed as: 38c6902637837befa316b23fb0c9e83270dec714b411b4ab4ef19ea59cd8892c=student1
The operator is now able to force a logout of the user by using the destroySession method with the associated sessionID as argument.
8.2.3. Metadata Management For each configured MetadataProvider of type ResourceBackedMetadataProvider an MBean is created dynamically using the following identifier: objectName="mseproject:type=Metadata,name=#MetadataResourceName#"
Managed Attributes Attribute Description r/w ExpirationDate The expiration date of the metadata r LastRefreshDate The last refresh of the metadata r LastUpdateDate The last update of the metadata r RequireValidMetadata Indicates if valid metadata is required r/w
Managed Operations Operation Parameter Return value refresh
Monitors & Notifications Nagios displays the available metadata information for every monitored provider, see Figure 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, see Listing 8.3.
# touch /etc/shibboleth/sp−metadata.xml Listing 8.3: Update Metadata Timestamp After waiting for a specific time (next refresh) or manually executing the managed operation refresh, the metadata is updated and a notification is sent, see Figure 8.9.
Figure 8.9.: MetadataChange Notification
8.2.4. Authentication For 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/w FailedAuthentications Current count of failed authentications r SuccessfulAuthentications 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 value resetFailedAuthentications resetSuccessfulAuthentications
Monitors & Notifications For each pair of LoginHandler and successful respectively failed authentications a javax.management.monitor.CounterMonitor in differenceMode is defined with a configured granularity period of one minute. This allows to measure the count of specific authentication types per minute and the definition of thresholds.
55 Graphs Figures 8.10 and 8.11 illustrate the login statistics of username password authentications over 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 authentications over 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 Performance The attribute processing performance data is available by the following MBean: objectName="mseproject:type=Performance,name=AttributeProcessing"
57 Managed Attributes Attribute Description r/w attributes.resolveMean The mean of attribute resolving in the last period r attributes.resolveMin The min of attribute resolving in the last period r attributes.resolveMax The max of attribute resolving in the last period r attributes.resolveStdDev The min of attribute resolving in the last period r attributes.resolveCount The count of attribute resolvings in the last period r attributes.resolveTPS Attribute resolvings per second in the last period r attributes.filterMean The mean of attribute filtering in the last period r attributes.filterMin The min of attribute filtering in the last period r attributes.filterMax The max of attribute filtering in the last period r attributes.filterStdDev The min of attribute filtering in the last period r attributes.filterCount The count of attribute filterings in the last period r attributes.filterTPS Attribute filterings per second in the last period r
Managed Operations None.
Monitors & Notifications 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, visualizing min, max and average values.
Figure 8.14.: Attribute Resolving
Figure 8.15 shows the performance of the attribute filtering over 2 hours, visualizing min, max and average values.
58 Figure 8.15.: Attribute Filtering
Figure 8.16 shows the performance of the attribute resolving and filtering over 1 hour using the Google Chart API.
Figure 8.16.: Attribute Processing
Demonstration None.
59 9. Conclusion
JMX-enabling an application can provide metrics and management tasks, which go far beyond legacy monitoring approaches (SNMP, parsing log files etc.). JMX provides a wide variety of possibilities to analyze, measure and change the run-time behavior of a system.
The main benefits for service operators are the fine-grained metrics and management tasks which provide high operation flexibility on one side and meaningful data about usage and performance on the other side.
This project demonstrated that enhancing the Shibboleth IdP with JMX support would considerably improve its scalable manageability.
9.1. Implementation
If the application is well structured into components, the introduction of MBeans is pretty straightforward, especially if a supporting framework such as Spring is used. The excellent design of the Shibboleth IdP facilitates the activation of JMX for the individual components.
The Spring JMX support using Java annotations is the most intuitive way to provide MBeans for an application. As outlined in Section 3.2 all major JMX functionalities are provided 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.x where inheritance of JMX annotations is supported.
For profiling the IdP and measuring particular method execution performance, the Perf4J library including its JMX appender proved to be very useful.
Generally, the activation of JMX support within the IdP can be archived with a little effort 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 the Shibboleth IdP 3.x.
60 9.2. Integration
Nagios is a typical network and infrastructure monitoring system with numerous plug- ins available for all sorts of system and application checking. The plug-in mechanism allows to write customized scripts with specified return values and information/perfor- mance data output. This flexibility has the drawbacks of maintaining these scripts and ensuring compatibility.
The JMX Nagios plug-in used for querying the MBeans is a good start but has some limitations like using/comparing non-number/string values (e.g., dates) and it doesn’t support the full Nagios performance data specification for min/max/avg data.
For organizations already operating a Nagios system, it could make sense to monitor certain 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 implementation based on e.g., the Google Chart API as well as specific management scripts for often used 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 systems like Munin [12] there are JMX plug-ins [11] available too, but were not considered in this 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. Outlook
The insights and experiences of this project were shared with the Shibboleth IdP lead developer Chad la Joie. The next major release of the Shibboleth IdP (3.0) will make use of the Spring JMX support to provide some components as MBeans.
61 Glossary
Discovery Service The Discovery Service, also called Where 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 related to the use, processing, storage, and transmission of informa- tion or data and the systems and processes used for those purposes.
Metadata Metadata is used to identify trusted IdPs and SPs. SWITCH provides signed metadata for the SWITCHaai federation.
SWITCHaai The Shibboleth-based production federation in Swiss higher education and research, coordinated and led by SWITCH.
62 Acronyms
AAI 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 in federated 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 Java Management Extensions. Sams, Indianapolis, IN, USA, 2001.
[27] James Won-KI Hong Jong-Tae Park, Jong-Wook Baek. Ip-oriented operations and management. IEEE Communications Magazine, 2001.
[28] Adrian Paschke. A categorization scheme for sla metrics. In in Multi-Conference Information 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 and design. 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 proposal
From: Halm Reusser To: Andreas Steffen (HSR) Cc: Thomas Lenggenhager, Chad la Joie, Christoph Witzig (SWITCH) Date: 17. December 2009
MSE Project Thesis, Spring Semester 2010
Project 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
Idea
The 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 of the SWITCHaai federation.
Planed Tasks
Defining 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 measure points.
• Defining a set of metrics, in a structured manner are beneficial for the SWITCHaai federation 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 effort required.
• 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 in the project thesis final report.
Possible Extension to a Master Thesis
The project may be continued as a master thesis. An idea is to coordinate a pilot between the AMMAIS project in Switzerland and a similar monitoring project in the United Kingdom. There is no commitment yet.
Research Aspect
Monitoring of distributed systems is still a research topic. The SWITCHaai federation is a quite complex distributed system with 40 IdPs and 370 SPs.
Intellectual Challenge
The intellectual challenge is to monitor the «right» thing or control through JMX, to answer the question: «What is beneficial for Identity Provider and Service Provider administrators» 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 Ideas for MBeans 70 D. Reporting
This appendix contains the weekly status reports.
Calendar Week 9
Work 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
Problems None.
Varia None.
Attachments • Documentation
71 Calendar Week 10
Work 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 11
Work 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.
Problems None.
Varia • Setup meeting milestone 1 on April 14th at SWITCH, confirmed
• ISV project thesis, first draft
Attachments None.
Calendar Week 12
Work 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 some MBeans.
• 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 MBeans etc.)
• Getting familiar with JMX architecture, standard services, registration etc.
• Process feedback by AMAAIS project.
• Think about best integration approach.
Problems Some of the implementation will be more or less complex. Figuring how the proposal for the implementation should look like. Are there some expectations.
Varia • ISV project thesis, sign and pass to the Master office.
Attachments Mindmap of the MBeans after review.
Calendar Week 13
Work 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 MBeans etc.)
• 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 through the 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 14
Work 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.
Problems None.
Varia None.
75 Attachments • Draft of current documentation. • Slides for milestone 1 meeting.
Calendar Week 15
Work 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.
Problems None.
Varia None.
Attachments None.
Calendar Week 16
Work 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 an well defined integration approach for JMX into Shibboleth IdP 3.x. → More flexibility in implementation, input for 3.x branch. • It seems that not only Shibboleth IdP code has to be adapted, but also Shibboleth common and OpenSAML as well.
Varia None.
Attachments Current documentation.
Calendar Week 17
Work 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.
Problems None.
77 Varia None.
Attachments Current documentation.
Calendar Week 18
Work 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.
Problems None
Varia None.
Attachments Current documentation.
78 Calendar Week 19
Work 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
Problems None.
Varia None.
Attachments None.
Calendar Week 20
Work 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.
Problems Attribute 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.
Attachments Screenshots of Nagios.
Calendar Week 21
Work 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 performance data.
• Reference performance chart using Google’s chart API [3]
Planned Work Items next Week • Configuration into repository.
• Plan demonstration.
• Documentation: Testing
Problems None.
Varia None.
Attachments None.
80 Calendar Week 22
Work 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.
Problems None.
Varia None.
Attachments None.
Calendar Week 23
Work Items done this Week • Preparation Milestone 2 meeting. • Documentation: Show cases
Planned Work Items next Week • Milestone 2 meeting • Documentation
Problems None.
81 Varia None.
Attachments None.
Calendar Week 24
Work Items done this Week • Milestone 2 meeting.
Planned Work Items next Week • Documentation
Problems None.
Varia None.
Attachments Milestone 2 presentation.
Calendar Week 25-28
Finishing documentation.
82 E. Milestones
Milestone 1
Date: April, 14th 2010 Place: SWITCH, Zurich Attendees: 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 papers concerning FIM metrics are respected.
• Specification proposal of MBeans, which will be implemented.
Results • Decision for a set of MBeans for implementation.
Proposal See 5.1.
Tasks Revision 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 the structuration and categorization of the metrics and management tasks.
Decisions The proposed set of MBeans for implementation was approved.
83 Milestone 2
Date: June, 16th 2010 Place: SWITCH, Zurich Attendees: 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.
Demonstration The demonstration includes some typical usage of the implemented MBeans like query- ing for a specific information, execute management tasks and visualization of statistical data.
Different clients (JConsole, HTTP adaptor and Nagios JMX plug-in) are used as well as different visualization methods (JConsole, PNP4Nagios, Google Chart API) and differ- ent notification mechanism (JConsole, Nagios web console and e-mail, LoggingListener and Logback SMTP appender).
For some demonstration cases, automated random logins are performed using the webtest framework [2], which will be introduced shortly as well.
The following use cases will be demonstrated:
Status Status monitoring, Starttime, Uptime, Version with notification in case of an outage of the directory service. Sessions Demonstration of administrative logouts. Session monitoring using WARNING 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 valid metadata (writeable). Authentication Visualization of successful as well as failed authentications of type UsernamePassword and PreviousSession. Notification for failed User- namePassword authentication threshold. Performance Visualization of attribute resolving and filtering performance.
84 Milestone 3
Date: July, 16th 2010 Attendees: Andreas Steffen, Halm Reusser
Deliverables • Final documentation as printout.
• DVD including virtual machine, documentation, source code, reference material etc.
85 F. DVD
The following content can be found on the DVD. bin
Used binaries such as the webtest framework [2]. shibboleth-sources
Sources of Shibboleth IdP, Shibboleth Common, OpenSAML, OpenWS and XMLTool- ing. svn-rep
The subversion repository of the project (i.e., the history of the working folder). tutorials
Several tutorials of JMX, Spring [22], AOP and Perf4J [16]. vm
The CentOS virtual machine with installed Shibboleth IdP (JMX enabled), Shibboleth SP and Nagios. The login credentials are root:prima10. working
This folder contains all project work divided into the following subfolders: documentation
The documentation as PDF as well as LATEX sources. The Milestone presentations are found within the slides folder.
86 implementation The branched versions of Shibboleth IdP, Shibboleth Common and OpenSAML with the implemented JMX extensions. The merge, install and deployment scripts. The branched and adapted version of the Nagios JMX plug-in. integration All customized configuration of the virtual machine like Apache Directory Server, Apache HTTPd, Jetty, Shibboleth IdP, Shibboleth SP, Nagios and Nagios plug-ins. testing The webtest to simulate parameterized random logins.
87