Skip to content

Understanding Inspektr

October 19, 2009
tags: ,

Inspektr library is an auditing aspect built inside CAS server.

This library has two aspects built in – one is AuditTrailManagementAspect and other is StatisticManagementAspect.

Like any other aspect class the above two classes are annotated with

@Aspect at top class definition and
@Around for managing aop method execution.

The notable points wrt this library are:
There is a custom annotation that is created called @Auditable (similarly @Statistics)
To create a custom annotation we need to define the class as follows:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Auditable {}

Then there are three parts to Auditing: (user info, resource info, action info)
Principal: User info
Resource: Ticket info (ST or TGT)
Action : type of ticket created info (Failure or success)

So classes providing this info are injected along to the AuditAspect class along with the name of the class that will know how to publish this information to the right output.

User info, we have the class called TicketOrCredentialBasedAuditablePrincipalResolver.
Resource: Service ticket info, ServiceResourceResolver
Action: ObjectCreationAuditableActionResolver (prefixes failure/success based on null value check of object)

One question can come is why are we keeping all the resources in the list of of constructer. Example if I only need to audit the service ticket creation or validation then should the references of other resources is needed? . The answer is that object creation of these resources takes place one time only in the construction of the aspect class so that these object handlers of resources can be used in different places (be it TGT or ST creation etc.) .

If there is no @Auditable tag kept only at the level of service ticket creation then only one resource resolver an be kept at the list level which is ServiceResourceResolver. (Note you would need to remove @auditable annotation from other places to avoid error)

<bean id="auditTrailManagementAspect" class="org.inspektr.audit.AuditTrailManagementAspect">
		<constructor-arg index="0" ref="auditablePrincipalResolver" />
		<constructor-arg index="1">
         	<list>
	         	<bean class="org.jasig.cas.audit.spi.CredentialsAsFirstParameterResourceResolver" />
	         	<bean class="org.jasig.cas.audit.spi.TicketAsFirstParameterResourceResolver" />
	         	<bean class="org.jasig.cas.audit.spi.ServiceResourceResolver" />
			</list>
		</constructor-arg>
		<constructor-arg index="2">
			<list>
				<bean class="org.inspektr.audit.support.ConsoleAuditTrailManager" />
			</list>
      	</constructor-arg>
		<constructor-arg index="3" value="CAS" />
   </bean>
<bean id="auditablePrincipalResolver"                         
                class="org.jasig.cas.audit.spi.TicketOrCredentialBasedAuditablePrincipalResolver">
		<constructor-arg index="0" ref="ticketRegistry" />
	</bean>

The class that manages the final bundle of information – i.e clubbing of complete info related to resource, principal and action is AuditableActionContext that stores all the data (strings of info) in it and the object of this class is then used by the manager that “records” the information in the right output. So for example the ConsoleTrailManager will do a simple sysout of the information.

 public void record(final AuditableActionContext auditableActionContext) {
        System.out.println("Audit trail record BEGIN");
        System.out.println("=============================================================");
        System.out.println("WHO: " + auditableActionContext.getPrincipal());
        System.out.println("WHAT: " + auditableActionContext.getResourceOperatedUpon());
        System.out.println("ACTION: " + auditableActionContext.getActionPerformed());
        System.out.println("APPLICATION: " + auditableActionContext.getApplicationCode());
        System.out.println("WHEN: " + auditableActionContext.getWhenActionWasPerformed());
        System.out.println("CLIENT IP ADDRESS: " + auditableActionContext.getClientIpAddress());
        System.out.println("SERVER IP ADDRESS: " + auditableActionContext.getServerIpAddress());
        System.out.println("=============================================================");
        System.out.println("\n");
    } 

So if you need to record additional information like browser info, session id , etc, then you need to see if you wish to extend Auditable or create your own custom Aspect class that will handle all the data.

Advertisements
One Comment leave one →
  1. lkafle permalink
    August 10, 2011 11:24 am

    great article for audittrail inspectr

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: