Hello,

I've been reading the Geneva white paper and have come up with some questions about how claims are verified by an STS.

My understanding is that an application already knows what claims it needs to know about, those claims get sent to an STS, which should end up creating a token. This is my first question: Can an STS connect to one or all Identity Providers such as(AD DS, an SQL database, etc) to verify the claims it received from an application at true?

My second question is, how do the identity providers verify that the claims it receives are true? I think i may have this all mixed up in my head but what im thinking an STS does is it takes the claims, and has to verify each one according to what identity provider that claim needs to talk to.

Thank you,

Hi LowTec,

You can think of the STS as being claims providers with claims coming in and claims going out.

In the case of the STS being an Identity Provider (here is where the orginating authentication for the user happens), the claims coming in is typically some sort of credential (u/pwd, x509 cert etc...) and the STS issues a set of claims to the requestor.

In the case of the STS being a Federation Provider (intermediate claims provider between the Identity Provider and the Application/Relying party), the claims come in as a SAML token and they get validated based on the token signature of the Issuer of this token. The STS may also do further validation on claim values (for e.g does the email address have "@contoso.com" as a prefix since the Issuer is CONTOSO) prior to transforming the claims to the next node (in most simple cases the Application/Relying Party).

The application/Relying Party typically does not send claims typically. When a user attempts to access the application, the application simply, by virtue of policy, asks the user to authenticate from a STS it trusts and when the issuer comes back with a token validates this token and extracts the claims for it.

Hope this clarifies and helps. I'm not sure which white paper that you've read, but David Chappell's white paper available at http://download.microsoft.com/download/7/d/0/7d0b5166-6a8a-418a-addd-95ee9b046994/Introducing_Geneva_Beta1_Whitepaper.pdfisusually a goodhigh level one.

Thx
--Sam

Hey Sam,

That is the whitepaper i read "Dave Chappell's"

The question for me to understand is once the STS gets the claims comming in (username, password, x509 cert, etc) it knows what the application is looking for in terms of claims comming back. I see how it verifies that the user is who they say they are at this point. but to return claims such as age, phone number etc, does/can the STS go out to multiple locations AD DS, SQL Database etc to get the information for those claims?

I've got a developer mindset on the whole thing more than the infrastructure side. Most of the time in a regular application i'd do what Dave was talking about, go to 2-3 different places to get the information (Claims) i needed to work with the application. I'm just wondering does the STS do that but from a centralized place, and how. If i was to get a claim such as age from the STS, it would need to know what Database to connect to correct?

So really, can one STS(Geneva Server)have a claim that it can send to another STS(AD DS) or STS(Applications Database) which sends a claim back to the STS(Geneva server).

Thank you muchly for the help.

Hi LowTec,

Do't worry - you are not the first person to get confused about Claims-based authentication.

In Geneva Server, the administrator sets up a Relying Party (RP). This is a consumer of the claims (like a web site or service). In the configuration the administrator specifies which claims shall be sent to this RP, and where those claims will be taken from. Currently this is only AD or from a federated token, but it is possible (and likely) that this will be extended to support other LDAP directories or identity stores, if necessary. They are then bundled up into a SecurityToken, which contains the claim set. The RP can then do as it chooses with those claims, in terms of authentication or authorisation.

I think your confusion arises from the fact that you see the STS as a consumer of claims, whereas in fact it is a provider of them. It is the RP that is the ultimate consumer of the claims.

How a RP trusts the claims is through the use of digital signatures. The token is signed by the STS, which the RP trusts (through the use of digital certificates), and so can then accept the claims contained within the token.

HTH

YoY

That fully clears up my confusion! Thank you again!

Hi Sam

When you said that ".... the claims come in as a SAML token and they get validated based on the token signature of the Issuer of this token ...", i am wondering which API is used to verify the signature? Is it done behind-the-scene by the Geneva Framework or developer has write code to verify the token signature? My scenario is i do not use Geneva Server, but instead create my own STS (Federation Provider). I checked on sample "Federation for Web Apps" but seems that, there is no code that is actually used to "verify the signature" but instead, only use to verify the issuer's certificates' information such as issuer name, subject, thumbprint and so on. Is that the same for "verify the token signature" and "verify the token issuer"?

Thanks
Tat Sean