Analyze Siteminder Logs

Here is the understanding of analyzing Siteminder Event logs

If the event category is authentication  or authorization , the format is:

lpszEvent lpszHostName lpszTimeString "szClientIp szUserName" "szAgentName szAction szResource" [szTransactionId] [nReason] szStatusMsg

The above format is described as follows,

• lpszEvent. The name (type) of the access event:

  SmLogAccessEvent_AuthAccept : lpszEvent = "AuthAccept"
  SmLogAccessEvent_AuthReject : lpszEvent = "AuthReject"
  SmLogAccessEvent_AuthAttempt : lpszEvent = "AuthAttempt"
  SmLogAccessEvent_AuthChallenge : lpszEvent = "AuthChallenge"
  SmLogAccessEvent_AzAccept : lpszEvent = "AzAccept"
  SmLogAccessEvent_AzReject : lpszEvent = "AzReject"
  SmLogAccessEvent_AdminLogin : lpszEvent = "AdminLogin"
  SmLogAccessEvent_AdminLogout : lpszEvent = "AdminLogout"
  SmLogAccessEvent_AdminReject : lpszEvent = "AdminReject"
  SmLogAccessEvent_AuthLogout : lpszEvent = "AuthLogout"
  SmLogAccessEvent_ValidateAccept : lpszEvent = "ValidateAccept"
  SmLogAccessEvent_ValidateReject : lpszEvent = "ValidateReject"
  

• lpszHostName. The name of the host.
• lpszTimeString. The timestamp of the occurrence of the event, in the format: [//:::
  ]. For example: [27/Jun/2000:11:27:29 -0500]
• szClientIp. The IP address of the client machine.
• szUserName. The name of the user.
• szAgentName. The name of the agent.
• szAction. The action associated with the resource.
• szResource. The accessed resource.
• [szTransactionId]. A string that contains: idletime=.
• [nReason]. The reason associated with the event. Reasons are enumerated in Sm_Api_Reason_t, which is in SmApi.h.
• szStatusMsg. The message associated with the event. The message depends on the event type, as shown in in the following table:

For example:

AuthAccept testbox [27/Jun/2000:11:27:29 -0500] "190.158.4.90 uid=scarter,ou=people,o=airius.com" "testagent GET /test/index.html" [idletime=3600;maxtime=7200;authlevel=5;] [0]

In this example,

• lpszEvent is AuthAccept
• lpszHostName is testbox
• lpszTimeString is [27/Jun/2000:11:27:29 -0500]
• szClientIp is 190.158.4.90
• szUserName is uid=scarter,ou=people,o=airius.com
• szAgentName is testagent
• szAction is GET
• szResource is /test/index.html
• [szTransactionId] is [idletime=3600;maxtime=7200;
      authlevel=5;]
• [nReason] is [0]
• szStatusMsg is not specified.

Siteminder Impersonation

Definition: Impersonation is a method where a Priveleged User assumes the identity of another user,without losing the privileged users session.

Example:

Admin URL : www.xyz.com  

Target URL: www.xyz.com/imperso/targetURL

EndUser Application : www.xyz.com/application

Impersonator : Priveleged User who can assume the identity of another user

Impersonatee :A User whose identity is assumed by the Impersonator

Request Flow:

1)Impersonator logs into Admin URL www.xyz.com which is protected by Siteminder .

Siteminder creates a SMSESSION for the Impersonator.

2)Impersonator clicks on the Target URL: www.xyz.com/imperso/targetURL which initiates Impersonation Journey since the Target URL is protected by Impersonation Authentication Scheme

Impersonation Authentication Scheme prompts for Impersonatee’s user name

3)Impersonator lands to the Target URL  as a Impersonatee

Siteminder creates a SMSESSION for Impersonatee and saves the Impersonators session as SMSAVEDSESSION

4)Now Impersonator assumes the identity of Impersonatee and access the End User Application.

5)Impersonator clicks logout to end Impersonation journey which does the following,

SMSAVEDSESSION Cookie of Impersonator gets restored to SMSESSION and SMSAVEDSESSION returns a NULL value

 

Siteminder Configurations:

In the above example ,Consider Imperso.fcc,Impersologout.fcc and TargetURL are placed under www.xyz.com/imperso/

Realm 1:Create a realm for /imperso/

Authentication Scheme : Impersonation Auth Scheme [www.xyz.com/imperso/Imperso.fcc ]

Rules : Get/Post,ImpersoStart,ImpersoStartUser

Realm 2 for Admin URL[It will be an existing realm which creates a SMSESSION for the Impersonator]

Authentication Scheme: HTML Forms Authentication Scheme

Rules:Get/Post [existing Rules]

Realm 3 for EndUser Application :[Existing Realm]

Rules:Create a ImpersoStart and ImpersoStartUser Actions for all the each existing Rules.

Policies:

Impersonator Policy :

Add all the ImpersoStart Rules under this policy.

User Group:Only Impersonator

Impersonatee policy:

Add all the ImpersoStartUser Rules under this policy.

User Group:Only Impersonatee

Access policy:

Add Get/Post Rule from Realm 1

As part of Impersonation,Imperso.fcc file as to be protected,Since FCC files are ignored as part of IgnoreExt parameter in ACO,Create the following:

OverrideIgnoreExt = /Imperso.fcc

Hope this Documentation Helps!!!Any Queries please comment

SM Session Cookie

SMSESSION cookie represents user's session and contains:

- User's ID

- ID of the directory or database from which the user was authenticated

- SMSESSIONSPEC

- Unique Session ID (a hash of the GUID of the logged in user)

- other proprietary information

The Web Agent is responsible for validating an SMSESSION cookie's integrity, session expiration timeouts, and session revocations.

The session-spec field of the SMSESSION cookie is encrypted as it is transmitted by the Web Agent to the Policy Server to take decision about authentication and authorization. By decoding the SMSESSION cookie, you get the information about:

SM_AGENTAPI_ATTR_USERDN

SM_AGENTAPI_ATTR_SESSIONSPEC

SM_AGENTAPI_ATTR_SESSIONID

SM_AGENTAPI_ATTR_USERNAME

SM_AGENTAPI_ATTR_CLIENTIP

SM_AGENTAPI_ATTR_DEVICENAME

SM_AGENTAPI_ATTR_IDLESESSIONTIMEOUT

SM_AGENTAPI_ATTR_MAXSESSIONTIMEOUT

SM_AGENTAPI_ATTR_STARTSESSIONTIME

SM_AGENTAPI_ATTR_LASTSESSIONTIME

Troubleshoot the Siteminder Agent for Sharepoint

Introduction

Siteminder Web Agent for Sharepoint is a quite complicated product to implement.

You will face many issues while installing it for the first time or even after. So it’s important to manage all the tools to debug and troubleshoot all the issues you will face.

The Agent For Sharepoint has many different products bundled together so you will have many places to take a look in order to find the black sheep.

Enable / Disable logs

Affwebservices logs

Edit $AGENTHOME/Tomcat/webapps/affwebservices/WEB-INF/classes/LoggerConfig.properties
Change the value of :
TracingOn to Y
LoggingOn to Y

Claims web services log

Edit $AGENTHOME/Tomcat/webapps/ClaimsWS/WEB-INF/classes/LoggerConfig.properties
Change the value of :
TracingOn to Y
LoggingOn to Y

Apache HTTP Server logs

Open $AGENTHOME/httpd/conf/httpd.conf
Change value of :
JkLogLevel to debug
LogLevel to debug

Tomcat logs

Open $AGENTHOME/proxy-engine/conf/server.conf and change the value of :
loglevel to 4
After all of these modifications, please restart Agent For Sharepoint in order to make the changes effective.

Path of logs

Affwebservices logs

$AGENTHOME/proxy-engine/logs/federation.log (and its trace in the same directory)

Claims Web Service logs

$AGENTHOME/proxy-engine/logs/claimswebservice.log (and its trace in the same directory)

Apache HTTP Server logs

$AGENTHOME/httpd/logs/error_log

Tomcat logs

$AGENTHOME/proxy-engine/logs/server.log


Source : http://guireg.com/2012/11/01/troubleshoot-the-siteminder-agent-for-sharepoint/

Authentication and Authorization events in Siteminder

Authentication Events
Authentication events occur when a user accesses a resource protected by a rule that includes an On-Auth event. Unlike Web Agent actions or authorization events, authentication events always apply to the entire realm. We can’t create an On-Auth rule that applies to a portion of a realm. Authentication events include the following:

On-Auth-Accept: Occurs if authentication was successful. This event may be used to redirect a user after a successful authentication.
On-Auth-Reject:Occurs if authentication failed for a user that is bound to a policy containing an On-Auth-Reject rule. This event may be used to redirect the user after a failed authentication.
On-Auth-Attempt: Occurs if the user was rejected because Siteminder does not know this user (an unregistered user, for example, can be redirected to register first).
On-Auth-Challenge: Occurs when custom challenge-response authentication schemes are activated (for example, a token code).
OnAuthUserNotFound – This event is only used to trigger Active Responses. This event should not be used to trigger any response other than an Active Response.


Authorization Events 
Authorization events will occur as Siteminder verifies whether or not a user is authorized to access a resource. As a rule action, an authorization event causes the Policy Server to fire a rule at a particular point in the authorization process. Authorization events include the following:

On-Access-Accept: Occurs when Siteminder successfully authorizes a user to access the resource.
On-Access-Reject: Occurs when Siteminder rejects a user because the user is not authorized to access the resource.

Source :http://vaibhav181.wordpress.com/2012/08/12/authentication-and-authorization-events-in-siteminder/

SAML 2.0 protocols
===============
Authentication Request Protocol
Assertion Query and Request Protocol
Artifact Resolution Protocol
Name Identifier Management Protocol
Name Identifier Mapping Protocol
Single Logout Protocol

The most important protocols of these are
Authentication Request Protocol
Artifact Resolution Protocol


The protocol is encoded in an XML schema as a set of request-response pairs. The protocols defined are.

Assertion Query and Request Protocol: Defines a set of queries by which existing SAML
assertions may be obtained. The query can be on the basis of a reference, subject or the
statement type.

Authentication Request Protocol: Defines a message that causes a
to be returned containing one of more assertions pertaining to a Principal.
Typically the is issued by a Service Provider with the Identity Provider
returning the message. Used to support the Web Browser SSO Profile.

Artifact Protocol: Provides a mechanism to obtain a previously created assertion by providing a reference. In SAML terms the reference is called an “artifact”. Thus a SAML protocol can refer to an assertion by an artifact, and then when a Service Provider obtains the artifact it can use the artifact Protocol to obtain the actual assertion using this protocol.

Name Identifier Management Protocol: Provides mechanisms to change the value or format
of the name of a Principal. The issuer of the request can be either the Service Provider or the
Identity Provider. The protocol also provides a mechanism to terminate an association of a
name between an Identity Provider and Service Provider.

Single Logout Protocol: Defines a request that allows near-simultaneous logout of all
sessions associated by a Principal. The logout can be directly initiated by the Principal or due
to a session timeout.

Name Identifier Mapping Protocol: Provides a mechanism to enable “account linking”.
Refer to the subsequent sections on Federation.

Source : saml

SAML Definitions

Definitions:
SAML 2.0 (Source : WIKIPEDIA )
========
Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is an identity provider, and a web service, that is a service provider. SAML 2.0 enables web-based authentication and authorization scenarios including single sign-on (SSO).

What is SAML?  (Source : SLIDESHARE )

=============

Security Assertion Markup Language

XML based protocol

OASIS approved standardSAML 1.0 November 2002

SAML 1.1 September 2003

SAML 2.0 March 2005

Flexible and extensible protocol designed to be used by other standards

SAML (Security Assertion Markup Language)    (Source : TECHTARGET )

=========================================

SAML (Security Assertion Markup Language) is an Extensible Markup Language (XML) standard that allows a user to log on once for affiliated but separate Web sites. SAML is designed for business-to-business (B2B) and business-to-consumer (B2C) transactions.

SAML specifies three components: assertions, protocol, and binding. There are three assertions: authentication, attribute, and authorization. Authentication assertion validates the user's identity. Attribute assertion contains specific information about the user. And authorization assertion identifies what the user is authorized to do.

Protocol defines how SAML asks for and receives assertions. Binding defines how SAML message exchanges are mapped to Simple Object Access Protocol (SOAP) exchanges. SAML works with multiple protocols including Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP) and also supports SOAP, BizTalk, and Electronic Business XML (ebXML). The Organization for the Advancement of Structured Information Standards (OASIS) is the standards group for SAML.