How To Break Web Software - A look at security...

I found below video on youtube and liked it. It is little longer in duration but worth watching.

Oracle database security and PCI DSS

Today I was browsing for data masking technology and products available in this space and found one good link on the oracle site.

This link explains each PCI DSS requirements in detail.

Strong Authentication by biopassword

I watched many sci-fi movies where guys were playing around on the keyboard and trying to hack someones system by figuring out password etc. You already know that every individual has his/her own way/speed of typing on the keyboard. Biopassword has made a product on such grounds. There product captures the keystrokes and builds a pattern in which user key in the password etc. During authentication there software checks for that pattern and denies the access if the pattern does not match. I have tested the demo on there site.

You check it out by yourself and have fun.

SAML and desktop SSO

Today I was reading a post and found one good blog which i would like to share with you. PingIdentity has developed Integrated Windows Authentication toolkit to provide SSO to Google application.

If you have read my post onSAML where I discussed how Google apps are using SAML for federated authentication to there applications like gmail/gtalk used by corporates with there domain like abc@company.com hosted using gmail interface. In that post I have mentioned under section 1-a that if user is already authenticated then identity provider will not ask for the credentials again to the user but directly give access to the Google application like gtalk/gmail etc.

Below diagram shows my understanding of how it might be working. I am not showing anything related to pingidentity implementation for this approach but it is completely my understanding for the solution.

Microsoft GINA component can be customized to get the user credential and Microsoft has also exposed API to set the cookie for Internet explorer. Keep in mind that all things are going through the user browser so if user has a cookie to some domain (identity provider) it will be sent to the server by the browser.

Similarly Cookie can be deleted on the event of user logout. If the solution needs persistent cookie can also be set which will expire after the persistence time.

ProQuo Implementation of centralized identity

Many people staying in USA (Sorry for being location specific as this implementation is done for USA) are suffering with tons of junk mails coming to there mailbox (Physical mailbox). Here publisher/marketing organizations send lots of advertising material to the mailbox which (80-90%) directly been dumped into the trash box next to the mailbox. It consumes billions of dollars cost of paper and postage.

This new site is a good effort to stop this unnecessary mails coming to your mailbox. Once you login/register at this siteProQuo it will display all the publications which you are getting. After registration you can view your current publications by clicking on the dashboard link.

Below image shows how ProQuo might be getting the publication information's from different marketing organizations.



Once a person registers with his [name/email and address] this site can show how many publications you have. They might able to collect this information based on your identity (Name + Address).

When I registered on this site and tried to stop some of the publications I got stuck with some paper work (You have to take the printout of the PDF file which has the letter to stop the publication and post it to the publisher). Problem with this is that most of the people have at least 10-15 publications. Every publication post is going to cost 50 Cents so roughly 5$ per household to stop all the junk publications.

Identity Solutions:

I feel that the wired solutions can be built to stop the physical communication between the user and the publisher. Following could be some of the ways to implement this

1) Using SAML: user assertion can be sent to the publisher over the wire. This SAML assertions can also contain the encoded PDF letter which can be used as a proof at the publisher.

2) Using custom Cryptography: User's signed PDF can be sent to the web service running at the publisher when user want to stop the publication.

Share your comments about how it can be implemented.

Technorati : federated identity management, identity control, identitycontrol

How Kerberos was evolved - Inside Story Part 2

In my last post I discussed few steps for the evolution of kerberos protocol implementation. In this post I am going to conclude it so read on...

Just want to recolect the problem statements where I left in last post so you get some continuity

Problems

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

For solving first problem Authentication Server (Ticket Granting Server [TGS]) will generate a sessionkey which will be sent to the user. TGS will also send a ticket encrypted with service password to the user. Below is the detailed structure

[SesssionKey:[*Service Ticket encrypted with service Key]]

* Structure of service ticket is [SessionKey:lifespan:issuing time:service name]

issuing time and lifespan are introduced so tickets can be valid for specific amount of time and not good for ever.

TGS will encrypt session key and ticket with user's password to solve the replay attack because password is only shared between user and Authentication Server.

Step by Step process for user authentication and service access

1) User enters the userid and KINIT program on the user machine sends that to TGS for authentication.

2) TGS server creates Ticket Granting Ticket [TGT] (this will be used to get service tickets)and send to the user by encrypting the whole content by users passwod.

3) User decrypts the TGT using the password to get the ticket. If someone spoof the packet then he will not be able to decrypt it as the password is shared between user and TGS only.

4) User wants to access his mail but user does not have mail service ticket so user contacts TGT for mail service ticket by submitting Authenticator,TGT, Name of the user and workstation address. This Authenticator with the session key sent by the TGS in the initial handshaking.

* Authenticator = {username:servie name: time stamp : lifespan}

5) TGS will get the session key of the user and decrypts the authenticator. After validating the identity it generates following and send by encrypting the whole content using the SESSION Key.

i) Ticket for the mail service. This ticket has the session key, service name, lifespan, timestamp and client address. This ticket is encrypted with the service password. (Even User can not decrypt it)
ii) Session key to be used to encrypt the conversation with mail service

6) User recieves the packet and decrypts the content using the session key (Given during first handshake with the TGS).

7) User prepares the Authenticator and encrypts it with the SESSION key (generated for the mail service communication in step 5).

8) Mail Service recieves the Authenticator and Ticket. Decryptst the ticket using it's password to get the session key. Using the session key decrypts the Authenticator. Validate the Authenticator and sends the acknowledgement to the user by encrypting the session key.

9) User receives the acknowledgement and start using the service.

How Kerberos was evolved - Inside Story Part 1

I always wanted to get something on kerberos (earlier name Charon) which can give me inside of the protocol like why,how, what etc...

In this post I am trying to explain this in some easy steps with problem and solution approach for the evolution of this protocol.

Below Image displays the first version of there discussion



Problem with the first version is that anybody can impersonate anybody easily so no security and accountability. There is no Authentication (NO PASSWORD) piece involved it is just the userid which you pass to get the service.

Below Image solves first problem by having a centralized authentication server. Every user and every service has a password which is stored in the authentication server named CHAROS.

Here is how it work

1) User Authenticates with the centralized server
2) Server authenticates the user and give him a TICKET (encrypted text which is encrypted with service password)

*encrypted text contains (Username and servicename and IP address of the user)
3) User passes this ticket to the service and service will verify user's identity to give access




Problems with this:

1) User has to authenticate every time user wants to use any service. For example user has got the TICKET for mail service but wants to print some mail then he has to again enter the password
2) Password is flowing on the network in clear text (people can capture the password on the network)


Above problem is solve by introducing another component called ticket granting service in the authentication service. It will grant the ticket which can be reused.

Another componet which is added at the system level is KINIT service which is responsible for handshaking with the authentication service. Here is how it works

1) KINIT service will take userid and password from the user and will pass the userid to the authentication service (it will NOT pass the password at all)
2) Authentication service will build the TICKET GRANTING TICKET and encrypt it with the user's password because it knows what the user password is.
3) KINIT will decrypt the token using user's password. If it is able to decrypt it successfully then user is authenticated.





Problems:

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

Keep reading this because I will post rest of the story in next post...

Free Sun Identity Management training

Today while browsing blogs for identity management I end up Marina Sum's Blog. She has posted the free 2 hour course from Sun to introduce about identity management suite and it's offering.

I mentioned last time that it is available only in USA but I asked my friend in Australia and he confirmed that it works there too.

Check it out.

Cross IDM product integration

In my coffee time I use to discuss with my friends about the projects on which they are working and how they are solving the problems. It could be related to IDM/IAM or it could be any other technology. Few days back I met with my friend who is working with web methods to integrate different applications. While discussing about it back of my mind was thinking can we have something which can help us integrating multiple vendor products related to IDM / IAM space?

I think yes, that kind of framework can be built using the SAML and SPML specification integration framework. At the root level these specifications talks XML language over HTTP/S channel. If we can build a IDM middleware component which can understand one product language (XML Schema) and convert that to another product language then our purpose is solved.

It looks like OpenPTK is one such open source project on which Sun is working on. They recently released latest version of it. It is providing multiple interfaces to connect to Sun IAM suite (Identity and Access Control suite). But I think this is the starting as this version of OpenPTK does not support cross product integration.

OpenDS (open source directory server)

I am always deep lover of Directory Server and technology behind it. I was very happy when I saw that Sun (I have worked mostly with Sun LDAP and I love it) is aggressively working on a open source directory server project OpenDS which will take the directory server to new levels. I was reading about the intension of this project and why they have not supported the current open source projects like openLDAP,Apache directory etc and the reason they feel is because they want to redesign it based on current client's requirements.

Below are the features in the openDS:

Performance Lots of features are important, but performance is almost always near the top of the list. It needs to be extremely fast, outperforming all other servers wherever possible.

Upward Vertical Scalability. It needs to be capable of handling billions of entries in a single instance on appropriately-sized hardware. It should be able to make effective use of multi-CPU, multi-core machines with hundreds of gigabytes of memory.

Downward Vertical Scalability. It needs to be capable of running adequately in low-memory environments so that all essential components can be functional on edge devices like cell phones and PDAs.

Horizontal Scalability. It needs be possible to use synchronization to achieve higher levels of read scalability by adding servers to the directory service. In addition, it needs to be possible to use data distribution in conjunction with synchronization to achieve horizontal read and write scalability to achieve deployments into the billions.

Supportability. The server should be easy to support and maintain. Administration should be intuitive, and wherever possible the server should provide sufficient information and notifications to enable corrective actions, even predictively.

Security. The server must provide extensive security in areas like access control, encryption, authentication, auditing, and password and account management.

Extensibility. Virtually every aspect of the server should be customizable. It needs a safe and simple plugin API that delivers additional points of extensibility, including, but not limited to, password validation algorithms, password generators, monitor information providers, logging subsystems, backend repositories, protocol handlers, administrative tasks, SASL mechanisms, extended operations, attribute syntaxes, and matching rules.

Synchronization. The server must support data synchronization between instances, including not only total data synchronization but also partial synchronization (with fractional, filtered, and subtree capabilities), and must also provide a means of synchronizing with other applications and data repositories.
Availability. The server must be robust enough to continue running properly even if serious errors are encountered.

Portability. The server needs to be written entirely in Java so that it can run on any platform.

Reliability. A directory service is one of the most critical components of a business infrastructure. It is absolutely essential that the service function despite hostile or unexpected events and that the data it delivers be trusted.

Compatibility. The Sun Java System Directory Server will continue to be maintained over time and will not be immediately replaced by Sun products based on OpenDS. However, OpenDS must provide support for virtually all existing features of the Sun Java System Directory Server. Migration from other directory server implementations should also be taken into consideration when applicable.

PCI Compliance

Next buzzword of the coming year going to be PCI DSS (Payment Card Industry Data Security Standard). Since lots of identity theft and sensitive information is being attacked now a days it is very important to secure the MONEY and where ever in any form MONEY is :-)

Main goal of this compliance is to protect credit/debit card information where ever it is:
1) Issuing Banks
2) Online merchants like Amazon (They also store the credit card information)
3) Utility companies like your electricity provider. Now a days every one and mostly everyone accepts the online payment.
4) Even the merchants in the local store should comply to this standard because they are also playing with the card information's. If the merchant is dealing with debit card and PIN combination then they are exempted for PCI compliance.

Companies needs to get the confidence of the customers to provide the sensitive information (credit card information) for any kind of payments.This compliance standard is going to help the industry achieving the same.

Below are the PCI Data Security Standard Control Objectives & Requirements

I. Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters

II. Protect Cardholder Data
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks

III. Maintain a Vulnerability Management Program
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications

IV. Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data

V. Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes

VI. Maintain an Information Security Policy
12. Maintain a policy that addresses information security

Cross Site Scriptting

Cross Site Scripting is a web application attack which is also known as code insertion attack. It is basically of two types

1) Insertion of script in the server side, for example in the database content. Hacker may insert the script in the database by using forum postings etc. These scripts gets executed when user browses that page which uses the content having the hidden scripts.

2) Insertion of script content in the URL. Hacker may send these URLs by the channel of email. When user gets the email and clicks on the link script gets executed on the system and will become active when user enters the credentials to get into the site. Script captures the credentials and post those details to the hacker site behind the scene. Some times attackers uses URL encoding/ UTF encoding / ASCII representation of the URL parameters so user think it as a genuine data and clicks the URL.

NEVER click the bank URLs coming in the email. Generally bank's don't send there site URL in the emails.

I liked the White Paper which talks about this attack in detail. It talks about how these attacks are exploited and what can be done to prevent these attacks. You can also visit XSS Faqs section for further reading.

Google also had the XSS vulnerability which was fixed earlier this year.

Technorati : XSS

SAML in Action

Today I was browsing the net to find more on SAML and came across a good implementation of SAML by google. In this post I am going detailed out my understanding of SAML implementation by google.

Security Assertion Markup Language(SAML): It is used in a federated environment where TRUST is needed between service provider (like google gmail, gtalk etc) and identity provider (any organization using google applications). Google is providing it's services like gmail, gtalk etc for enterprises who wants to use these applications with there corporate domain. To enable these services and provide Single Sign On between corporate network and google application network SAML can be used.

Below diagram shows four main entities used for SAML implementation

1. Actor : User using the application hosted at service provider


2. Service Provider : In this case Google exposing it's services like gmail, gtalk etc.


3. Identity Provider : Corporate using the google services.


4. Repository : Store for holding the user base for the identity provider.

Step By Step Flow of SAML in Action

1) User accesses the service hosed by the service provider. There could be two different scenarios

a) User is already authenticated at the corporate (identity provider) :If user is already authenticated, identity provider will set the session in the cookie. This cookie will be passed to the user when service provider redirects the user for SAML assertion. Identity provider will validate the cookie and pass the user information in the assertion to the service provider without asking user to enter the credentials.

b) User is directly accessing the service without logging into the corporate portal: If the user is accessing the service without logging into the corporate network user will be asked to enter the credentials when service provider request for an assertion at the identity provider.

2) Service Provider requests for an assertion: As we know that SAML request and SAML response (assertions) are sent using XML over HTTP/S, it is mandatory to define the XML structure in which service provider will request for the assertion and identity provider will respond with an assertion. Google has also defined such schema's. Google is also using the RSA/DSA key pair (public/private) to validate the assertion sent by the identity provider. Corporate using the SAML SSO needs to generate the key pair and register the public key with google assertion validator (This is the component residing at the service provider [in this case google] to extract the user information from the assertion).

3)Identity Provider generates and sends the assertion: Identity provider will authenticate the user based on two cases mentioned in step 1 and passes the userid to the service provider.

Since we can not pass directly XML documents as the request parameters (GET/POST) over HTTP it is required to encode the SAML request and SAML responses.

Samples of the SAML request/responses

SAML Request XML format

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="fpagejpkbhmddfodlbmnfhdginimekieckijbeei"
Version="2.0"
IssueInstant="2006-05-02T08:49:40Z"
ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect"
ProviderName="google.com"
AssertionConsumerServiceURL="https://www.google.com/hosted/psosamldemo.net/acs"/>

Encoded Request passed to the identity provider

identity_provider.html?SAMLRequest=eJxdkE1PwzAMhs%2F9F1XubcM00IjWTQOEmDTQtA8O3NrEa7M1donTjZ9P2UAgrraf1489nn64Jj6CZ0uYi6tUihhQk7FY5WK7eUxGYjoZc%2BGaVs26UOMK3jvgEEc9iKzOnVx0HhUVbFlh4YBV0Go9e16oQSpV6ymQpkZE84dc7Nqign17KGtnzI5MUzrc1aayaB0cLOiD3ZcAVsTR649Wn9LDzB3MkUOBoS9JeZPI60QONnKkhrdqKN9EtPxedWfxcsE%2Fr%2FSvV3kZYvW02SyTFRjrQYdzyNEa8C89kYuKqGog1eRENGMGH3qle0LuHPg1%2BKPVsF0tclGH0LLKstPplP5CWU0cwGQt09erDDhKEUJWaBbZ5BPy1YRc&RelayState=http%3A%2F%2Fwww.google.com%2Fhosted%2Fpsosamldemo.net%2FDashboard

SAML Response Generated at the Identity provider

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
ID="hedangifkfodeigidaeijpdnfjkfbnegddealebo"
IssueInstant="2006-08-17T10:05:29Z"
Version="2.0">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>sJAWNV9VzT+CghjrHsJSXAY9DRk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>X9Fx4pFSOlI2byrLXBw8azq26xxdqeF7w1UfQtcZ5l7HfXfkq9Tp2w==</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9jQTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
<Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
<Y>VMoV//Oh7VytBbZVySNmVZevV1bw7vmJwx5hHszeR25bforBFA19nk+3ehg6SgUjWiXn7HsybemjRFs5x4+XFg==</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="dojnoaponicbieffopfdecilinaepodfimmkpjij"
IssueInstant="2003-04-17T00:46:02Z"
Version="2.0">
<Issuer>https://www.opensaml.org/IDP </Issuer>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> demouser </NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</Subject>
<Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2008-04-17T00:51:02Z"> </Conditions>
<AuthnStatement AuthnInstant="2006-08-17T10:05:29Z">
<AuthnContext>
<AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password </AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

Technorati : SAML

Technorati : SAML

How to View cookies in browser

Often a times we have to test what cookies are set on the browser during testing a issue. Everyone has figured out there own way of doing this. I would like to share the way I do this during troubleshooting.

1) You can use javascript:document.cookie on the browser window to check the cookies. Problem with this is that the content of the page is gone and you have to reload the page to see the page content. Use second approach to solve this problem.

2) Alternate to this approach is to use the javascript ALERT as javascript:alert(document.cookie). If there are one or two cookies this is fine but if number of cookies are more then reading the alert box becomes a pain. Use third approach to overcome this problem.

3) Use javascript:alert(unescape(document.cookie).replace(/;/gi,"\n\n")) to get the cookies displayed separately.

RSA Conference 2007

I got an opportunity to attend RSA conference here in Savannah (Hilton Island). It was more of a partner oriented conference but they talked about there product line and gave some of the new features of the products which are going to come in the market in next fiscal year.

I attended seminars on following products:

1) Authentication Manager 7.1 (Will be in the market in Mar-Apr 2008)
This product main focus is on Strong Authentication (one time password using hardware and software tokens). Software token is the good feature where in if the person forgets to carry the hardware token he can get the software token using self service. User has to answer security questions and software token will be sent to the user on either SMS or in a email.

They are also working on putting the software in the mobile phones for generating the token instead of carrying the separate device.

While attending the conference I asked how the software works on the cell phone? Is it the same software for all the users or is it user specific? I know these are silly questions but I never hesitate to ask questions so I did. They told me that software is same for everyone but the SEED is person specific and they also told me that one SEED can be assigned to three devices at the max at a single point of time. For example same SEED can be given on persons cell phone and same can be used for the hardware token also.
More on Authentication Manager in later posts after I can recollect my understandings.

2) RSA Key Manager

This product helps in managing the symmetric and asymmetric keys in the organization. It can be either for RSA products or it can also be used to manage encryption keys for home grown applications.

3) File Security System

RSA wants every content to be written in a secure manner and should be accessed by authorized persons ONLY. That is the reason they accuired a company who were in this area. This software works for putting the file contents in a secure manner and you can protect whole folder. You can then assign persons who can access those files and folders in a secure manner.

4) Database security System

This product secures the content of the database at a column level.

I will talk more about the inside of these products in the comming postings so keep reading.

Federated Access Control

Generally I hate do a copy paste of the content from other sites but I liked this one a lot (because of cute animations) so thought of sharing the same with my friends watching my blog.

DSML Introduction

Directory Services Markup Language (DSML) provides a mechanism for accessing directory servers as XML document. It evolved with version 1.0 which just gave flexibility to read the directory servers but version 2.0 came with more flexibility. Using version 2.0 directory server entries can be updated.

DSML functionality is motivated by scenarios including:

1) Hand held device which does not have LDAP client.
2) Applicaion programs developed using XML tools and application needs to access LDAP.
3) A program needs to access a directory across the firewall and firewall does not allow LDAP ports.
Click on the below image to view the animation.

4) Integrating two different vendor directory servers.

Most of the existing directory server vendors support the DSML but it needs to be enabled explicitely. Below are some links specific to Sun DS.

How to enable DSML support

Accessing Directory using DSML

DSML tools are also available for integration with existing applications.

Technorati : dsml introduction

How to enable special character support on Sun Directory Server?

Organizations in today's world are spreaded across the globe and they want to have a support of all the character set in the applications so there user's can access them at any part of the globe in there local language.

To enable Special character support in Sun DS follow below steps

1) Login into the directory manager console
2) Open the instance on which you want to enable special character support
3) Go to Configuration Tab
4) Expend the plugins
5) Select "7 bit check" plugin and disable it. By default it is enabled.
6) Restart the server and now you are all set to dump special characters in the Directory Server.

Same activity can be done using the command line but I am not posting that part here.

Servlet Filter and SSO

Servlet Specification 2.3 came with many new features. One of such feature which is used for Single Sign On (SSO) implementation is Servlet Filter. Below image gives an outline how servlet filters can intercept request and response headers before content is reached to the destination.

Servlet Filters can intercept incoming request and check the header variables, It can also make dynamic decisions after validating the HTTP Headers.




How Servlet Filters can be used for SSO:

Agents responsible for providing SSO functionality use Servlet Filters to intercept every request before it hits the destination. Filter intercepts the session header variable in the request and checks against the Session Manager of the Access Control product. If the Session coming in the request is valid then it passes the requst to the other component of the agent for further processing like role validation etc. If the Session is not valid then User will be redirected to the login page. In the below diagram I tried to detailed out some of the J2EE agent components.

SSO vs centralized authentication

Single Sign On (SSO) provides a mechanism in which user is authenticated only once and then given access to various applications. Behind the scene it might be possible that systems are authenticating/authorizing the user with different systems. SSO works mainly with web based applications. We can not (easily) achieve SSO for logging into Unix servers or non web based applications.

Centralized authentication helps user in such cases. User will have to enter the credential multiple times but they will be same. All the applications will authenticate the user against the centralized repository (like active directory or another LDAP or common database). Since all the applications are authenticating user against one server user don;t need to remember multiple credentials. Also once user account is terminated in the centralized system user can not access any of the application user has access to.

Inside Active Directory Password Filter DLL

I had posted a blog How to get plain text password in Active Directory??? to give some inside of how to write password filter DLL.

In this post I am going to talk about some issues and precautions should be followed while writing these components.

Like a user account Active Directory maintains computer accounts in it's repository. It enforces the same password policy which is applicable for user accounts. For example if there is a policy to change the password after every 30 days for the user accounts same applies to the computer accounts stored in Active Directory. This policy can be disabled for computer accounts but that leads to some security issues over the network because these accounts (computer accounts) are used to provide some kind of internal authentication when you access shared resources over the network like printer or some shared folder etc.

Computer accounts password change notifications should be ignored while passing the credentials to the identity management(IDM) products ( I am assuming that you know why this is done???) for synchronization. If password filter DLL will send these computer password change notifications to the IDM products it will not be processed as these products are not managing computer accounts.

Every computer account has an attribute named samaccountname which has a DOLLAR ($) character at the end. Password filter DLL should check if the sAmAccountname of the event is terminating with DOLLAR then it should skip the whole process. This provides two benefits
1) Increases the efficiency of the password filter DLL as it is skipping the processing of unnecessary accounts.
2) Better utilization of network bandwidth.

Hope this tips help you building more efficient password filter DLL.