views:

8

answers:

0

All,

I'm a little confused over some of the concepts behind Windows Intentity Foundation and the overall architectural fit in a third-party "trusted" environment as regards Authorisation. I think I may have missed something but I can't see how it would work in the real world.

As an example, we have a number of systems behind a portal. Customers can access the portal and, based on their permissions they can access features of each different application. In the current scenario, we may have a single authentication step (user id/password) that passes the authorised identity/principal (against a custom authentication store) to each application. The application then uses this pre-authenticated identity to look up against its own roles to allow users access to certain features.

This is all managed internally - i.e. each application understands its own roles so each application has its own admin function that maps a user to a role.

Ok, so it works but is a pain to manage and our customer has to remember our portal user id and password.

I'd like to move to a trusted environment so that we trust the token from their STS and authentication is all hidden. However, I simply cannot see how Authorisation will work - we're asking that each third party implement roles in their STS to pass along with the token. We've shifted the admin to them which may break their security models anyway.

So we cannot delegate authorisation to them, and still need to manage the map of a trusted token to the roles the application requires.

So the great benefit of trusted STS, whereby user A leaves trusted company 123 and user B joins to take over, and they don't have to wait for us to make any changes..... just isn't practical in the real world.

Which is a shame, as I really like the idea.

Have I missed something fundamental?