IdentityServer v2 beta is done!
You can get it from the new thinktecture organization page on github as well as the new project page for IdentityServer (or directly from the download page).
What’s new?
Well – on the surface IdSrv 2 does look very much like v1..but we made a number of changes under the hood to accommodate for all the new features that will be in the box for the final release…and of course everything is now based on .NET 4.5, MVC 4, WCF and ASP.NET Web API.
Overall architecture
IdentityServer now consists of two main parts: front-end and engine:
The front-end includes hosting support for web hosting in IIS/ASP.NET and self-hosting for endpoints that don’t require a UI. Furthermore IdSrv ships with a number of built-in protocol implementations that sit on top of the host. These protocols handle requests, make use of the IdSrv engine for token issuance and emit the corresponding response. Protocol support can be extended by adding new implementations to the host and using the common engine for the heavy lifting.
The IdSrv engine consists of the core runtime and configuration, data and user management. The core runtime takes care of enforcing security policy and token issuance whereas the data repositories abstract the underlying user and configuration store. By providing custom implementations of these repositories, IdSrv can be adapted to arbitrary user management and configuration systems.
Configuration
The old configuration system was a bit of a dead end. We re-worked that completely, and it is now much easier to add new features to it. This also meant we had to re-write the whole configuration admin UI. It is now more modular and extensible and the UI is much more consistent (and also in a way that using the right CSS you could make it look really pretty ;).
User management
By default, IdSrv will now store the users in a local SQL Compact database. This was mainly done to reduce the friction during initial setup. No more need to use other (non-existing) tools to populate a fresh membership database. It also includes basic user and role management now directly in the admin UI. So it should be really easy to get a basic STS up and running. You can of course use a different database or location, either by using membership or by providing your own repository.
Extensibility
We added a number of extensibility points to make it even easier to extend and customize IdSrv. This includes the user management part and claims transformation. It is now also easier to add custom claims from within the web interface (a much demanded feature).
Some of the protocol endpoints are self-hostable, and the core engine can be also used in other arbitrary hosts. We will provide a sample how to do that later.
Protocols
For the beta we support:
- WS-Federation (both with username and client certificate credentials)
- WS-Trust (message and mixed mode security, usernames and certificates)
- OAuth2 Resource Owner Password Credentials flow
- Simple HTTP GET
For the final release we will add the capability to federate with other identity providers – at least for WS-Federation maybe also WS-Trust.
I will also add more OAuth2 flows – especially the implicit flow to support native/client side web applications.
Token Types
For the beta we support SAML 1.1/2.0 and JWT (with symmetric signatures).
What’s next?
First of all we need your feedback! Contact us at @leastprivilege or @brocklallen – or – better- use the issue tracker on github if you run into problems or have general comments.
Most of the pending features are already prototyped, we just needed to get the new core done. So we should be able to deliver incremental updates really soon. If you like living on the edge, clone (or fork) the repository directly, we do constant check-ins and additions.
Have fun!
Pingback: Windows Azure and Cloud Computing Posts for 10/12/2012+ - Windows Azure Blog
Did IdSrv support SAMS2-P ?
No.
Can you point me in the right direction to use my own user repository? I am not finding any examples online
Well – there are no docs really.
But simply implement IUserRepository (and probably also IClaimsRepository) – and register them in repositories.config. The interfaces are not complicated and you can have a look at the default implementations as a sample.
The code could not be posted. I meant can we remove
membership defaultProvider=”DefaultMembershipProvider”
and
roleManager enabled=”true” defaultProvider=”DefaultRoleProvider”
from the web.config or do we have to replace that by our own user provider?
Don’t really understand the difference between MembershipProvider and UserRepository.
The UserRepository calls the provider. If you have a standard asp.net provider – you can swap it out. Otherwise you can implement the Repository to call an arbitrary data store.