index > Claims based access platform (CBA), code-named Geneva > Geneva Server, Geneva Framework-based Web Services and smart client - what is best practise?

Geneva Server, Geneva Framework-based Web Services and smart client - what is best practise?

Hi,

We're doing a project with Geneva Server serving tokens to a bunch of WCF/Geneva Framework-based Web Services. The only client right now is a smart client.

The smart client's users come from the Geneva Server AD and also other federated ADs. The question is, how should that smart client authorize access? I'd like it to use claims, but the claims only exist in his relation to a specific service when he accesses it and a token is issued for that target. So, what is the best practise to get the user's claims to a particular service out in the client? I see several possibilities:

1) Use a WSTrustClient in the client to get the token for a service and use that directly by looking in the attributes of the assertion. For example I'd look up an attribute with the group namespace and thus determine if the user is a member of a particular role.

2) Expose methods for authorization on the service. Eg: public bool CurrentUserIsAdministrator(), public bool CurrentUserIsManager()

The ideal case (as I see it anyway) would be to have claims on the client just like I do on the service, but a client isn't a target and thus it doesn't have an end point to receive tokens on.

So, what do I?

Jesper Hvid

I now understand your scenario.
My suggestion would be to have methods like public bool EnablePrivilegedOperation() on the service side. This will keep the logic localized in one place (service). So if any changes required in future, there is one place to change it (rather than changing in client app also).

Marked As Answer byJesper Hvid Monday, August 10, 2009 9:30 PM

Rakesh Bilaney - MSFT

I used an R-STS to solve this problem. The smart client first obtains an identity token. With that identity token the app acquires another token from a resource sts for the target service(s). The display claims of that token contains the action/permission claims that are relevant for the UI to enable/disable UI elements.

I used WSTrustClient for that. If you don't want to have a dependency on Geneva on the client - you could also use some special methods on the service (as suggested above) or have a special service that returns the UI authZ information.

HTH

Dominick Baier | thinktecture | http://www.leastprivilege.com

Marked As Answer byJesper Hvid Monday, August 17, 2009 8:06 PM

Dominick Baier

Hi Jesper,
I feel the bettersecurity practicewould be for the authorization decision to happen on the service.
If the authorization decisions were built into the client app, it is still possible for a malicioususer (who is part of the AD and can authenticate) to write their own client application and invoke the privileged service operations. Hence, the authorization should happen on the service side.

So (2), where the service would check the roles for the incoming request should be the approach you take.

Thanks,
Rakesh

Rakesh Bilaney - MSFT

Hi Rakesh,

Thanks for you reply.

But what about enabling/disabling UI based on specific roles the user is a member of with relation to a particular service? How would I go about doing that? I agree that authorization about what the service is offering should happen on the service and only there. However, I might want to disable a part of the UI if a user didn't have a particular role in this context. Do you see my point?

Jesper Hvid

Marked As Answer byJesper Hvid Monday, August 10, 2009 9:30 PM

Rakesh Bilaney - MSFT

I suppose.. I don't really like it but I guess you're right :)

Jesper Hvid

HTH

Dominick Baier | thinktecture | http://www.leastprivilege.com

Marked As Answer byJesper Hvid Monday, August 17, 2009 8:06 PM

Dominick Baier

Hallo Dominick,Grüß Gott

I like that solution more, but more on a conceptual level and in the words of Geneva Server: Is a client a relying party with an identifier? Is it crazy to think that an RP identifier has to be a physical URL (because that what I'm thinking)?

Also, just to make sure that I understand your scenario correctly:

1) I'm guessing the client requests the token from the same STS that the services have trust to?

2) The client then proceeds to use the one of the STS' own issued tokens for authentication against other services trusting that STS

3) The STS identifies the user based on the identity token and the repopulates new tokens for each service

It's very elegant, but it does seem a bit heavy on the coding on each client having to know wstrustclients and doing some if not a lot of programmatic channel creation.

Anyway, definitely the best idea I've heard so far.

Rgds.

Jesper Hvid

Hi ;)

first of all - RP identifiers don't need to be physical urls necessarily. In my case i only used a single RP service so it was easy. But you could also come up with identifiers that map to a group of RPs.

1) yes
2) i used the token from the r-sts to talk to the RPs. They also contained authZ information for the services in addition to the UI
3) yes

The original idea was simply that is the UI needs some claims, they should come from a STS. So i don't need to come up with my own serialiation format and can re-use IClaimsPrincipal on the client. The R-STS/diplay tokenconcept just did fit nicely in my scenario.

Yep - you definitely need to write some plumbing on the client.

Dominick Baier | thinktecture | http://www.leastprivilege.com

Dominick Baier

Thank you, I'll definitely take this into consideration.

Jesper Hvid

You can use google to search for other answers

Custom Search

More Threads

• Protocol transition from SAML 2.0 passive to WS-Federation passive

• Geneva Server configuration fails with AddressAccessDeniedException

• Will the Geneva Beta2 run on Windows Server 2008 SP2?

• Error "MSIS3046" using PassiveFederation

• Relying Party (Passive) / SecurityTokenException?

• Framework SDK on Windows 7

• Exception Handling with Geneva

• Problem with Core Vista Audio

• Error creating a local STS from Visual studio

• Sharing FederatedServiceHostConfigurationBehavior with Multiple Services