Siteminder Authentication

Siteminder Authentication

SiteMinder is a centralized Web access management system that enables user authentication and single sign-on, policy-based authorization, identity federation, and auditing of access to Web applications and portals.

It is a third party authentication provider: http://www.ca.com/in/secure-sso.aspx

Request Flow

SiteMinder can be deployed in both proxy server and agent configurations. The agent configuration installs a software agent on the web server and is the configuration addressed by this article.

The following steps occur when a user tries to access a protected resource on a web server configured to use SiteMinder authentication:

1.       The user requests a resource on the server, either through a web browser or in a program using an HTTP request.

2.       The request is received by the web server and is intercepted by the SiteMinder web agent.

3.       The web agent determines whether or not the resource is protected, and if so, gathers the user’s credentials and passes them to the Policy server.

4.       The Policy server authenticates the user and verifies whether or not the authenticated user is authorized for the requested resource, based on rules and policies contained in the Policy store.

5.       After the user is authenticated and authorized, the Policy server grants access to the protected resources.

In step 3 above, if no SiteMinder session exists, users are redirected to a login page where they are prompted to enter their credentials. Once the user is authenticated, a cookie is added to the response headers, creating a SiteMinder session. When this cookie is included on subsequent requests, the user is directed to the original URL without further prompting.

See the dia here: http://www.codeproject.com/Articles/80314/How-to-Connect-to-a-SiteMinder-Protected-Resource

 

IN MY EXPERIENCE I HAVE WORKED ON THE MIGRATION OF A WINDOWS AUTHENTICATION PROTECTED SERVICE TO SITEMINDER PROTECTED ONE…The Siteminder Agent was set up on the Windows Server, and the site hosted on IIS site/secure path…

IMPLEMENTATION IN IIS: http://serverfault.com/questions/7257/how-does-iis-integration-of-ca-siteminder-work-asp-net-application

Siteminder IIS agent is an ISAPI filter/extension. It sits in the web server and passes through requests to the underlying page which no changes required on the page as long as you can look to a header for the authenticated user ID. The agent handles all the redirects for authentication and will preserve the originally requested location so that after authentication the user is sent on to the correct page.

http://stackoverflow.com/questions/10148666/how-can-i-trust-that-the-siteminder-http-headers-havent-been-tampered-with

 

To try to compare between SM ,and IWT, I searched for:

  1. siteminder vs integrated windows authentication
    1. SM allows Anonymous at IIS and avoids any use of Active Directory.
  2. 2.      SITEMINDER VS KERBEROS SPNEGO AUTHENTICATION
    1. Needless to say, all these SSO solutions need additional proprietary components (either RSA Access Manager, or CA SiteMinder Policy Server, or IBM Tivoli Access Manager) to make it happen. Here I will present a way to set up SSO for Webtop where no extra component is necessary. The approach is to rely on SPNEGO support from Internet Explorer or Firefox. The underlying authentication protocol is Kerberos.: HTTP://DMDAA.WORDPRESS.COM/2009/12/24/SPNEGO-BASED-SINGLE-SIGN-ON-SSO-SETUP-FOR-WEBTOP/         this is the BEST…
  3. SiteMinder Kerberos Authentication:
    1. https://support.ca.com/cadocs/0/CA%20SiteMinder%20r12%20SP3-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?1614713.html
    2. https://enable.ca.com/answers/us/CA-SiteMinder/12.51-CA-SiteMinder/guide/1614713?parameters=&q=&page=4

 

Advertisements

NTLM vs Kerberos

NTLM vs Kerberos

Wiki: http://en.wikipedia.org/wiki/NTLM

In a Windows network, NTLM (NT LAN Manager) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users

Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains.[5] Kerberos is typically used when a server belongs to a Windows Server domain, or if a trust relationship with a Windows Server Domain is established in some other way (such as Linux to Windows AD authentication)

While Kerberos has replaced NTLM as the default authentication protocol in an Active Directory (AD) based single sign-on scheme, NTLM is still widely used in situations where a domain controller is not available or is unreachable. For example, NTLM would be used if a client is not Kerberos capable, the server is not joined to a domain, or the user is remotely authenticating over the web.

 

NTLM and Kerberos

NTLM is still used in the following situations:

The client is authenticating to a server using an IP address

The client is authenticating to a server that belongs to a different Active Directory forest that has a legacy NTLM trust instead of a transitive inter-forest trust

The client is authenticating to a server that doesn’t belong to a domain

No Active Directory domain exists (commonly referred to as “workgroup” or “peer-to-peer”)

Where a firewall would otherwise restrict the ports required by Kerberos (typically TCP 88)

In Windows Vista and above, neither LM nor NTLM are used by default[citation needed]. NTLM is still supported for inbound authentication, but for outbound authentication NTLMv2 is sent by default instead. Prior versions of Windows (back as far as Windows NT 4.0 Service Pack 4) could be configured to behave this way, but it was not the default.

Protocol

NTLM

It is a challenge-response authentication protocol which uses three messages to authenticate a client in a connection oriented environment (connectionless is similar), and a fourth additional message if integrity is desired.[7][8][9][10]

  1. First, the client establishes a network path to the server and sends a NEGOTIATE_MESSAGE advertising its capabilities.[11]
  2. Next, the server responds with CHALLENGE_MESSAGE which is used to establish the identity of the client.[12]
  3. Finally, the client responds to the challenge with an AUTHENTICATE_MESSAGE.[13]

The NTLM protocol uses one or both of two hashed password values, both of which are also stored on the server (or domain controller), and which are password equivalent.

 

KERBEROS

Kerberos /ˈkɛərbərəs/ is a computer network authentication protocol which works on the basis of ‘tickets’ to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.

Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other’s identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

Kerberos builds on symmetric key cryptography and REQUIRES A TRUSTED THIRD PARTY, and optionally may use public-key cryptography during certain phases of authentication. [1] Kerberos uses TCP port 88 by default.

Windows 2000 and later use Kerberos as their default authentication method.

http://en.wikipedia.org/wiki/Kerberos_(protocol)

BEST : http://technet.microsoft.com/en-us/library/bb742516.aspx

 

Kerberos and NTLM Options for Integrated Windows Authentication iis 7.5

Integrated Windows authentication actually encompasses two different authentication protocols: Kerberos and Windows NT Challenge/Response, also known as NTLM. When this authentication protocol is enabled, IIS sends the following HTTP headers to the browser:

• WWW-Authenticate: Negotiate

• WWW-Authenticate: NTLM

Ref: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8feeaa51-c634-4de3-bfdc-e922d195a45e.mspx?mfr=true

 

 

WAS LOOKING FOR THIS ALL ALONG: Windows authentication supports two authentication protocols, Kerberos and NTLM, which are defined in the <providers> element. When you install and enable Windows authentication on IIS 7, the default protocol is Kerberos. The <windowsAuthentication> element can also contain a useKernelMode attribute that configures whether to use the kernel mode authentication feature that is new to Windows Server 2008. Ref:http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication

 

 

The Negotiate header indicates that IIS can negotiate which of the two Windows authentication protocols to use. Internet Explorer 5, or later, recognizes this authentication header and determines which of the two authentication protocols to use. The NTLM authentication header is used as a fallback for browsers that do not support the Negotiate authentication header.

My Desktop Client, consuming a ASMX svc (Hosted on IIS with Windows Auth Enabled) was doing Kerberos Auth with the Server.

This is because, in the proxy class it says :

httpRequestToConnect.Credentials = CredentialCache.DefaultCredentials;

ALSO NOTE THAT THE ABOVE LINE OF CODE DOES THIS: http://stackoverflow.com/questions/19731347/where-does-defaultcredentials-pull-out-username-as-a-username-for-a-web-reques

The DefaultCredentials property applies only to NTLM, negotiate, and Kerberos-based authentication.

DefaultCredentials represents the system credentials for the current security context in which the application is running. For a client-side application, these are usually the Windows credentials

Ref: http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials(v=vs.110).aspx

THIS WORKED WITH MY ASMX PROXY BUT WITH WCF, I HAVE TO CHAGE IT THIS WAY: http://social.msdn.microsoft.com/Forums/vstudio/en-US/0aac0110-187e-4a00-a597-f15b768cf16c/passing-client-credentials-to-wcf-service

 

Q : What is the role of active directory in Integrated Windows Authentication ?

Ans: IWA uses Kerberos that needs a KDB. AD is an eg. Of a KDB. Read on  : http://stackoverflow.com/questions/13767439/using-windows-authentication-with-active-directory-groups-as-roles

Further Reading:

  1. See: http://msdn.microsoft.com/en-us/library/ff648505.aspx for server side Configurations
  2. Impersonation Options : http://msdn.microsoft.com/en-us/library/ff647405.aspx
  3. http://wahlnetwork.com/2013/09/09/using-active-directory-integrated-windows-authentication-sso-5-5/ : I’ve used SPN in the past…

 

Online Image Hosting

In the process of going completely digital, I am scanning a lot of docs these days.

I need a good hosting site so as to upload the pics there and:

  1. imbed them in my posts
  2. share with others

Now the biggest problem is that usually when I blog, I upload the images on my desktop using PicturePaste, which hosts them on a remote server (unown to me) and when I do a ctrl + v on the post, it imbeds the <a href> in the page.

Now, though that’s convenient, the issue with it is that I don’t have control of my pics and so can loose them anytime…

Hence I have decided to take control of this and upload my images to a online hosting site on my own.

Here are the options:

  1. WordPress Blog: This is the best and most logical option as then the images will stay on the Blog itself and also be secure and bound to my posts
  2. http://tinypic.com/
  3. http://photobucket.com/
  4. http://imgur.com/

Another holistic solution is http://www.shutterfly.com/downloads/express_uploader.jsp?esch=1 which provides a desktop client for easy and bulk uploads.

Ok so I tried it out and turns out that the Desktop client is Bogus as it has the same features as the online tool…

Anyways the site looks good and in fact even gives you a free website that u can customize….

I created this: https://tkhemanipics.shutterfly.com/

Oh. Wait… this is not an Image Hosting site, so I cannot imbed the images from here to my Blog…

Whoa that sucks…