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.

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

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.

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.

Single Sign On - Reduced Sign On

SSO provides flexibility to the user so they don't have to enter the credentials again and again for accessing different applications. Every one of us are happy about it but there is a side effect of this solution. For example if you are logged into the system which works on SSO and does the SSO to the payroll site. What will happen you signed into this portal and went for a cup of coffee with your friend and forget to lock the system. Your neighbour who is always intrested to know how much you are earning gets a chance to move his chair to your desk and get that information quickly.

This was just an example, there could be multiple secure applications which reside in enterprise portal and are critical for you. That's the reason organizations are adapting the concept of Reduced Sign On.

Reduced Sign On: This concept handles the above scenario by prompting another set of verification when you try to access critical applications. This extra layer of authentication could be any one of below list:

1) Challenge Question

2) Digital Certificate

3) Hardware Token number

4) Smart Card

5) Biometrics

Reducing users' sign-on complexity problems requires a balance between user satisfaction and security. If the scale swings too far toward security when trying to prevent a breach, user satisfaction decreases. Similarly, if the scale swings toward user satisfaction, you can compromise IT security.

Importance of Time Server in SSO environment

Once I deployed an SSO agent on a client location and was scratching my head for weeks to find what is that which is stopping the SSO to work properly. I checked my configurations hundred of times installed the SSO agent on other server with same configuration and it works there but what the hack is going on with this machine which is creating this issue. I checked the OS patch and everything but still NO LUCK !!!

In this article I am going to talk little bit about the root cause of that.

Time Server: SSO Token contains a time stamp which is generated by the server to check the session timeout. My server was residing on a box which was having a time stamp say T and my agent was residing on a box which was having a timestamp T+30 min. Session expiry was 30 minutes.

That's why whenever my agent box gets the SSOtoken and validates the token it always gets the token which is expired.

In the SSO environment please make sure all the servers are having time clock synchronized otherwise you may also have this tricky to debug situations.

List of SSO Products

Here are some of the industry wide used SSO products.

• Single Sign-On (Computer Associates)


• SecureLogin (Novell)


• AccessMaster Single Sign-On (Evidian)


• AccessMatrix Universal Sign-On (i-sprint)


• ActivIdentity SecureLogin (ActivIdentity)


• Entrust/SignOn (Entrust Technologies)


• MetaPass SSO (MetaPass)


• OneSign (Imprivata)


• OpenSSO (Sun)


• Passwerks (ASG Technologies)


• SecureLogin (Protocom)


• SP Sign-On (Unisys)


• SSO Plus (PassGo)


• Tivoli Global Sign-On (Tivoli)


• V-Go(Passlogix)

Technorati : SSO products

Is probing login.jsp from loadbalancer good option???

Loadbalancing is good for applications for failover conditions. Loadbalancers needs to know the status of the server for redirecting the clients. Many a times people thinks of pointing to login page for load balancer. This seems to be simple but think about the complication of a login page before pointing from load balancer.

Before describing the responsibilities of login page i would like to give an example of load balanced application.

There are two servers behind the load balancer and if a user is logged into one server(Server 1) and directly goes to another server (Server 2). Server 2 should not redirect the user to login page again as backend is same for both the servers.

Now lets see what login page responsibilites are
1) Check if the user is authenticated or not.
2) If the user is authenticated then redirect the user to requested page.
3) Check what access control user has to access the application.
4) Cache the user access rights if user is authenticated.

These are some of the examples and for performing every operation Login page has to call lots of vendor specific API's which are costly and some times they have memory leaks.

Think about a scenario when load balancer is configured to probe each server every 5-10 seconds.

Think again ????

I hope you might have already guessed that Login page is not the right approach at all.

Then what is the solution???

It's always better to build a very light weight application or simple page which is hosted on the server which tells if the server is up or not.

But this will just tell if the server is up or not, what about the repository server which server contacts???

You question is absolutely correct. But again instead of configuring Login page which is costly as discussed above it's better to build a custom page which just checks if the backend repository is up or not.

Hope this helps to some of my friends reading this article.

Technorati : Load Balancer and login page