What is OpenIAM?

As the number of users in your organization grows so does the potential for security risks, such as Identity Theft.  In addition, lost/forgotten passwords are accompanied by costly and time consuming calls to the help desk.
OpenIAM is an Open Source Identity and Access Management system that lets you keep your organization secure by effortlessly controlling users’ access to sensitive materials, and automates otherwise tedious tasks through Single Sign On and Self Service. For more details on how OpenIAM improves the user experience, click here. 

More Here

Courtesy: http://openiam.org/

Salesforce.com Single Sign On using ADFS v2

This is the universal identity problem – too many user accounts for the same person.  As such, one of my internal goals here is to simplify identity at ObjectSharp.
While working on another internal project with Salesforce i got to thinking about how it manages users.  It turns out Salesforce allows you to set it up as a SAML relying party.  ADFS v2 supports being a SAML IdP.  Theoretically we have both sides of the puzzle, but how does it work?
Well, first things first.  I checked out the security section of the configuration portal:

There was a Single Sign-On section, so I followed that and was given a pretty simple screen:

There isn’t much here to setup.  Going down the options, here is what I came up with:
SAML Version
I know from previous experience that ADFS supports version 2 of the SAML Protocol.

Issuer
What is the URI of the IdP, which in this case is going to be ADFS?  Within the ADFS MMC snap-in, if you right click the Service node you can access the properties:



In the properties dialog there is a textbox allowing you to change the Federation Service Identifier:

We want that URI.
Within Salesforce we set the Issuer to the identifier URI.
Identity Provider Certificate
Salesforce can’t just go and accept any token.  It needs to only be able to accept a token from my organization.  Therefore I upload the public key used to sign my tokens from ADFS.  You can access that token by going to ADFS and selecting the Certificates node:

Once in there you can select the signing certificate:

Just export the certificate and upload to Salesforce.
Custom Error URL
If the login fails for some reason, what URL should it go to?  If you leave it blank, it redirects to a generic Salesforce error page.
SAML User ID Type
This option is asking what information we are giving to Salesforce, so it can correlate that information to one of their internal ID’s.  Since for this demo I was just using my email address, I will leave it with Assertion contains User’s salesforce.com username.
SAML User ID Location
This option is asking where the above ID is located within the SAML token.  By default it will accept the nameidentifier but I don’t really want to pass my email as a name so I will select user ID is in an Attribute element.
Now I have to specify what claim type the email address is.  In this case I will go with the default for ADFS, which is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
On to Active Directory Federation Services
We are about half way done.  Now we just need to tell ADFS about Salesforce.  It’s surprisingly simple.
Once you’ve saved the Salesforce settings, you are given a button to download the metadata:

Selecting that will let you download an XML document containing metadata about Salesforce as a relying party.
Telling ADFS about a relying party is pretty straightforward, and you can find the detailed steps in a previous post I wrote about halfway through the article.
Once you’ve added the relying party, all you need to do is create a rule that returns the user’s email address as the above claim type:

More Here

Courtesy:http://blogs.objectsharp.com/cs/blogs/steve/archive/2011/02/14/salesforce-com-single-sign-on-using-adfs-v2.aspx

Using Simple Web Token (SWT) with WIF

SAML 1.1/SAML 2.0 is the default token format when using ACS as the authentication service for your website. In this model, your website talks to ACS using WS-Federation protocol and what it normally gets back is a Saml token. This scenarios is fairly straight-forward as WIF natively supports WS-Federation protocol & SAML1.1/SAML 2.0 token formats.
There are cases where you might want to return a Simple Web Tokens (SWT) after a successful authentication. For example, you might want to use this same SWT (available as a bootstrap token) to call other downstream REST/OData services as depicted in the following diagram.



ACS fully supports returning an SWT token after a successfully WS-Fed authentication but WIF currently doesn’t support SWT tokens. You would have to write a custom Security Token Handler for WIF to process SWT tokens coming back to your website. I have created some extensions which enables this and other OAuth WRAP related scenarios. Feel free to download the code from my SkyDrive.

More Here

Courtesy:http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/

Access Control Service Architectural Model

The Access Control Service is an easily configurable, cloud-based Security Token Service (STS) that supports the authentication of user name/password, Windows CardSpace, certificate, and third-party STS-issued SAML tokens and provides an authorization framework that uses flexible, claims-based rules. The Access Control Service uses the same basic architectural model for Web applications, Web services, and smart clients. In the basic scenario, there are three participants:

The Access Control Service STS.

An application that trusts the virtual Access Control Service STS (Relying Party).



The application that uses the Relying Party (Requester).

These participants interact with one another in the following manner, discussed in more detail in this section:

A trust relationship is established between the relying party and the Access Control Service STS. The owner of the relying party provides the Access Control Service STS with its certificate. This certificate is used by the Access Control Service STS to encrypt tokens that the relying party will accept.

Before the requester can use the relying party, the owner of the relying party application defines access control rules in the STS. These rules logically grant the requester access to the relying party.

The requester sends a WS-Trust 1.3-compliant Request for Security Token (RST) to the Access Control STS.

The Access Control STS receives the RST, and uses the input claims in the RST to initiate processing of the Access Control rules defined in that STS.

After Access Control rule processing, the Access Control STS packages the output into a SAML security token, signs the token, encrypts that token with the certificate provided in step 1, and sends the token back to the Requestor.

More Here

Courtesy:http://asher2003.wordpress.com/2011/02/14/accesscontrolservice-architectural-model/