0
votes

I want to create azure mvc4 website (azurewebsites) with:

  • SSO for employees within company's domain (ADFS already federeted with ACS)
  • access for external (non-employees) by local accounts or LiveID OAuth (liveid is IdP on ACS).
  • The Requirement is manage user profiles and roles within the application.

I see the following options:

  1. Federate my app with ACS and use Federated Authentication, Create custom set of tables for UserProfiles and Membership etc, in this approach i cannot use any existing provider. I do not have necessary information in Claims.

  2. Write custom OAuth/OAuth2 client for ACS (I cannot find any) and use OAuthWebSecurity to register it. This approach seems to be right for me, I can use SimpleMembership etc. The problem is that I can't find any examples how to implement it in the correct way.

Q:

What is the right approach in this scenario?

Is there any other option to fill my requirements ?

Is there any OAuthWebSecurity client for ACS?

Thanks, Maciej

3

3 Answers

1
votes

I'd go for approach 1. because -

a) you need ws-fed anyways to incorporate ADFS b) There is no OAuth client for ACS - ACS only supports some special use cases of OAuth (thats why you have not found a client for it).

You want full control over you database anyways - and not use the magic/half baked (depends on your viewpoint) simple membership stuff...

1
votes

We have recently implemented a solution to a similar problem. What we did was:

  • Use ACS and identity providers (Windows Live, Google, etc) for identity tokens
  • Use our own mechanism to map those identities to users/roles. For example we use payroll data on the first login to validate the claim against an employee.
  • For those users that don't want to use a social media identity, we allow them to create a username/password on our 'own' identity provider linked in via ACS. This is a separate service and runs a modified version of Thinktecture Identity Server. So we use the thinktecture identity service as an STS endpoint.
  • We will do the same for federated ADFS (as you have done)

Over time, it seems that we can use the Thinktecture server to replace the ACS functionality, and provide more control than is available in ACS (such as using our own domain name), but for now, ACS works, and we'll leave it at that. But the Thinktecture service, as an alternative login for simple username/passwords, is important to us — it does mean hosting a separate cloud service however.

What are you wanting out of SimpleMembership? The username/password login (in which case use/host/build a username/password STS endpoint), or the membership/roles tables (which aren't that great anyway).?

0
votes

There is an OAUTH2 client framework in ASP.NET, and I for one wrote an ACS provider for it. The web app loads a OAUTH2 provider that is a facade for an OAUTH2 endpoint. In reality, it talks ws-fedp to ACS (and its various issuers). Since the oauth protocol or the ws-fedp protocol alike is hidden in the provider, the API consumer (the ASP.NET pipeline) doesn't know (or care). After all, its already not care whether it was talking OAUTH1, OAUTH2, or openid behind the same API.

its very effective - and reuses simplemembership with no fuss. Works in web forms, web pages and MVC. The latter 2 are open source, whose source access helps see the bigger picture.