I just uploaded version 1.2 of AuthorizationServer.
The big change is that AS is now using MVC and Web API v5.1.1 – additionally there are some bug fixes and a new configuration switch – set the following appSetting to false if you want to pass through all incoming IdP claims (default is true):
<add key=”authz:FilterIncomingClaims” value=”true”/>
I have a question that’s more about architecture. There’s a lot of possibilities with OAuth2 and I wonder what’s the right flow to use in our scenario.
We work in DDD. Therefore, everything is implemented as services for the different domains. The resource owner identifies with the web app using ADFS. After that, we’d like to pass credentials (claims) to the different services via NServiceBus. Since we want to decouple Authentication from Authorization, we want to use AuthorizationServer to get a JWT and pass it in the message header. The mechanics exists in NServiceBus and it’s quite easy to implement. But I wonder what kind of flow should we use. Based on the samples that are in your project, I’d say something like client credentials flow but I don’t get the user creds. The resource owner flow could also works, but I don’t need to re authenticate the RO since he is already authenticated and we already have the SAML token.
What would you recommend us for that situation ? (we don’t want to go with passing SAML token since it’s a little too big to carry).
Sounds like a typical scenario for assertion flow – you send the SAML token to AS – and it gives you back a JWT in return.
I had previously read those posts, but I thought it wa only for Windows Store app. But you clearly mention it could be any other id provider. Seems good for our needs. Thanks for your help !
Hi there! thanks for your valuable work!
That being said, I was wondering if there are any plans to separate the core AS api from the administration dashboard?
I want to publish the AS as a self host service on my servers, and I wan’t to keep the admin UI separated from that. So this self host service will only contain the core authorization APIs and nothing related to the UI.
THANKS A LOT!!!
AS is done. But we did exactly what you suggest in v.next which you can find here: https://github.com/thinktecture/Thinktecture.IdentityServer.v3
We are not done yet though.
Yeah, I built the EF storage for this one since you didn’t include it on the preview 1 (Or did you release it and I didn’t know about it? ;( )
But I want to use some of the features of AS like the application/client/scope relationships that IdSrv doesn’t have built in and I don’t want to use AS UI to setup the configuration (I have my own UI look and feel and Admin dashboard). As you state on most of your videos, keep authorization and authentication separated, thats what Im trying to do..
I might not be making sense here, I don’t know hehe
Anyways, thanks a lot, really love your work with security stuff.
Yea as I said – it is not done yet ;)
Scopes are the new applications – took me a while too realize. The application partitioning is mostly in the way…that’s why IdSrv will be different.
IdSrv3 is a combination of idsrv2 and AS. Though you could disable one or the other part is needed.
Do you have any idea when preview 2 or final or whatever version will be available for us? I’m not pushing, I’m just eager to play with it
RC end of summer. fingers crossed ;)