Showing posts with label Federated Identity Management. Show all posts
Showing posts with label Federated Identity Management. Show all posts

Tuesday, October 23, 2007

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 : , ,

Saturday, October 13, 2007

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 :




Technorati :

Monday, October 8, 2007

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.

Hub and Switch and Router

I was doing a udemy course to learn more about the networking concepts and wanted to clarify the confusion between Hub, Switch and Router. ...