0

I need an authentication/authorisation module for my SaaS web app and am liking the look of WIF. The problem is that apart from Active Directory there doesn't seem to be a plug and play way to serve claims. My idea is to use IdentityServer and replace the ASP.NET Membership Provider repository with my own one.

The trick is

  • The app Internet facing with many different customers. (So ADFS2 is not applicable).
  • I want granualar operation level permissions, not roles. (So ASP.NET Membership is not suitable)
  • I want the users within my app to manage their own subset of users.

The bit I intend to build is the pinky coloured box below called the 'Claims Server'.

IClaimsService would allow things like creation of new users, creating roles, assigning permissions to roles and assigning users to those roles. My own application would auth the admin screen that plugs into the IClaimsService and auth a users permission to create a sub user etc.

My question is - is this a valid architecture or am I completely missing the point of WIF?

or is there an alternative plug and play option that I haven't found? I'm happy to not reinvent the wheel!

IdentityServer architecture

Additional Info

My web app is a SaaS which needs to allow my customers to create their own users within their own walled garden of data.

Think for example of a recruitment software platform where you have competeting teams of recruiters who have their own clients in the system. One team is not allowed to peak at another teams data but each team can manage and administer their own subset of users. There could be many different companies using the platform so there is not a central IT dept / Domain that would administer this. It's all self service.

I've had a look at netsqlazman which is close to what I want but Windows Identity Foundation looks like it will have more long term benefit as I wire in new customers and could connect their own STS to mine for authentication.

Community
  • 1
  • 1
fiat
  • 15,501
  • 9
  • 81
  • 103
  • 1
    It's a good architecture. You might want to consider looking at https://github.com/hibernating-rhinos/rhino-security because it already implements a complete authorization/permission model. – Henrik May 22 '12 at 15:16
  • Btw, if you are pursuing this, I'd be interested in making it play nice with messaging. – Henrik May 22 '12 at 15:16
  • ah - Rhino Security looks intersting but I've already embarked upon building this system. Forgive my ignorance - what is 'playing nice with messaging'? I'm toying with throwing it up on GitHub but I need to refine the concepts first. – fiat May 24 '12 at 12:19
  • I mean; you probably want to have some sort of messages in a system of the complexity that you are building if you require an STS. Messages that cause state changes in the rhino security database; commands and queries and read models and events and what not. Having only Request-Reply services leaves you pretty vulnerable. So if you want a helping hand with exposing the API with messaging, I'm interested. – Henrik May 24 '12 at 15:31
  • i see - thanks. well i'm near finished reinventing my own wheel :) but I'll put a note back here when i put it onto gitHub in any case – fiat May 26 '12 at 06:21

1 Answers1

1

I think you are correct that WIF will set you on the right path longer term. Claims based identity is here to stay, and where all things are converging. WIF makes it much easier to implement than in the past.

My recommendation would be to start with the simplest possible thing, and that is to authenticate users using claims first. Then associate a user handle (e.g. e-mail, or user_id, etc.) to whatever authorization architecture you build in the app. Could be membership, a custom database, etc.

The provisioning and self-admin you describe is all app specific and has nothing to do with the identity provider of choice (e.g. IdentityServer or anything else compatible with WIF: SAML tokens, WS-Federation, etc).

This simple step will prepare the foundation to more sophisticated solutions over time, and would allow you to offer instant value with marginally increased effort. For example, you could allow users with their social identities to logon to your site. You would still define: "fiat@mail.com" -> "can manage users" in your app.

Over time, you will find that the are common, recurrent attributes that you can further externalize (e.g. roles). Then something like what you propose would make sense.

One clarification: ADFS authenticates only against AD, but can retrieve attributes from anywhere (a database, LDAP, custom, etc).

Eugenio Pace
  • 14,094
  • 1
  • 34
  • 43
  • thanks Eugenio - good to know I'm on the right track. I'm currently building out the authorisation bits and can see how the WIF would plug in nicely. – fiat May 24 '12 at 12:13