What is Geneva?
Geneva is a three part solution to security in The Cloud or your internal network. These three components include an STS, a SAML identity token, and a RP. (Don’t worry, we’ll explain these acronyms in a moment.) This triangle of security and the open standards that power each component create a portable, federated security solution. To aid in rapid adoption, your application(s) will only need to incorporate one of the three components. Much of the heavy lifted in this security solution is executed outside of your application making it simplistic to provide single sign-on functionality across the enterprise. Since Geneva and each of its components are built on open standards, you can implement it in .Net, Java, and LAMP applications.

Geneva Proof of Concept:
For additional information about the benefits of implementing Geneva, Microsoft has created the following Proof of Concept video about the Lake Washington School District.

Geneva Components: The security triangle

STS – Security Token Service:
The Security Token Service is the core of the Geneva offering. The Geneva STS server provides an authentication service and does not serve as the data store for user credentials. Unlike past attempts at single sign on the Geneva server is not dependent on a single means of storing user credentials. In the Geneva product, one of the configurations set by the admin is the data store. Geneva can reference active directory, other STS servers, or a variety of other information sources to obtain the users identity. The STS then issues SAML Identity tokens or Identity Cards to the user, once the user is authenticated.

Since Geneva Server is only an STS or Token provider, you can comfortable utilize one of Microsoft’s hosted Geneva servers in The Cloud without comprising your user data store. Alternatively, you can purchase the Geneva Server product and host it within your network infrastructure.

SAML (Security Assertion Markup Language) Identity Token:
A SAML Identity Token is a serialized collection of identity data. In the case of the Geneva system, this token is referred to as a Geneva “CardSpace”. This identity card is stored locally on the client’s device(s) and contains data specified by the user and the STS server. These customizable cards can contain pertinent identity information, such as, name, email, user name, roles, and most importantly, an encrypted key that is generated by the STS server to identify the user.

RP – Relying Party:
An RP or Relying Party is any application or device that requires authentication and authorization for one or more of its functions. This could be a secure web site, a web service, an application, etc... For the purpose of this article, we will imagine that your website is the replying party.

In a basic Geneva user flow, your website is presented with a SAML Identity Token instead of the traditional user name and password. Your site can then extract the identity data contained in the token. This data includes information about the STS that issued the token. Your website can then take one of many courses of action. We will discuss 3 basic actions to demonstrate the simplicity of Geneva. (These are not Geneva best practices)
1) If No SAML is presented or the SAML was issued by an STS you do not trust, your website can passively redirect the client to a trusted STS for authentication.
2) If the SAML was generated by a trusted STS, your website could automatically consider the user to be authenticated.
3) For a higher level

You do not have flash or javascript support.

Average (0 votes)

Reply