We are trying to split apart Authorization and Authentication into two separate services. Both will use Identity Server 4. We may someday add in additional external Authentication providers. I believe Federated Gateway is the term (http://docs.identityserver.io/en/release/topics/federation_gateway.html?highlight=Federation)
My research so far indicates we are able to setup Authorization as External Providers and set [LocalLoginEnabled] to false. This works fine for web apps, since it redirects along the traditional flows. Our requirement is to have both Web-based and client-apps (Windows and Mobile) calling our solution. This would need Implicit or Resource Owner (password) flows.
Looking for guidance on the best way to set this up. I'm tempted to write a custom endpoint API to relay the authentication to authentication instance.
QUESTION:
How can I achieve "password flow" between two ID4 instances (Authorization + Authentication)?
Thanks in advance!
After much research and little guidance, I decided to take a leap and just created a new API Endpoint used only for Resource Owner / Password Grant Types. This API simply validates the necessary information was present grant-type, secret, user/pwd etc... and then relays it to the Authentication instance. There may be more "elegant" ways of doing this, but this one seems to be working.
Hope this might help someone.
Although my original answer worked, it was not the best way to accomplish my end result. Instead of creating a new endpoint, I am able to inject my own handling of password grants by extending the IResourceOwnerPasswordValidator. I can then have a single endpoint for all authorization. This solution is more "natural" and falls inline with the intended architecture.
The IResourceOwnerValidator interface just implements one function...
public Task ValidateAsync(ResourceOwnerPasswordValidationContext context)
A much more elegant solution.
Related
I would like to know if it is possible to implement impersonation in IdentityServer 4, and how to do it.
Did not find anything useful in my researches, and it seems, by reading IdentityServer4 pulls on github that it is not doable at the moment. Even searched for "impersonation" for OpenID Connect and Oauth2, but nothing...
Anyway does anyone knows how to do it?
Thanks in advance
Nothing stopping you from implementing it yourself but I think anything beyond representing an impersonated session via claims is outside the scope of the protocol.
OIDC itself does not offer any guidance in this area but this draft spec does:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-14#section-4.1
In our case we loosely followed this and used the act claim to store claims relating to the impersonator and used the amr claim to indicate if impersonation was used by using the value imp.
The rules and flow around who can impersonate who and when is entirely up to you. In our solution end users are able to grant impersonation permissions to specific users but this facility can be locked down via customer-controlled policies too. Users with valid impersonation grants get an extra step in the sign in flow that allows them to choose which user to impersonate.
I'm trying to implement an OAuth2 provider for my web service.
It seems easier to implement the Authentication Server together with the Resource Server. The specification doesn't say anything about the communication between them.
Does anybody see a reason not to do this?
I had a post yesterday regarding this issue. I hope we can mutual answer each other. First to directly answer your question, I think it depends very much on the load that your app has to handle. If you have to scale your app to many resource servers, keeping a separate auth server is the best because you can centrally manage user credentials and access_token in one place.
Here is my question. I believe if you have tried something similar to mine, you can give me some suggestions.
OAuth - Separating Auth Server and Resource server returns invalid token when accessing protected resource
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.
I am working on an asp.net mvc-4 web application and I have started implementing some web services which provides statistical information about my site. But to make sure that only authorized and authenticated consumers can call and consume the web services I am thinking of defining a master login username and password for each consumer, and when a consumer sends a web service request he should include these master login username and password (stored as a hash value ) in the web service calls.
For example the web service link to call specific web service from my web site will look as follow:-
/web/json/statistic/getsummaryinfo/areacode?j_username=masterusername&hash=D012B772672A55A0B561EAA53CA7734E
So my question is whether the approach I am following will provide a secure solution to my web services and to the consumers? OR my approach have security holes I am unaware of ?
:::EDITED::
I am using the WebAPI controllers to implement the web services inside my asp.net mvc-4.**
Best Regards
There are a few ways to make sure things are secure.
http://techcrunch.com/2012/11/08/soa-softwares-api-management-platform-and-how-it-compares-to-its-sexy-counterparts/ This article just came out today highlighting some API tools. I'm not sure how big you are or are planning to be, but if you're looking for scale, these tools seem to be pretty popular (note: I haven't had a large scale API project myself, so I haven't used these).
You can use something like ServiceStack to build your API layer. It has authorization and authentication built in with a boatload of authentication providers. It scales well and, after a call to authenticate, is session-based so you don't have to authenticate each call.
You can use "signed" requests. Signed requests often look something like: "take all the parameters for the request as a querystring, append a 'secret consumer key' to the end of the request', and then sign the request by appending the md5 hash of the results (without the secret key!!) to the request." This is a safe way of doing things because even if the request is made client-side (AJAX) it is generated server-side using a secret key. So you can ensure that things weren't tampered with.
You can go the oauth/token route (which often still uses method #3 above).
You can go with a simple API key that can be revoked (again, fotne used with method #3). bit.ly uses this method I think.
Option #2 is my favorite. I like ServiceStack. But to be honest the learning curve for your first project can be a little steep.
A master username and hashed password feels weak to me, so I'd strongly consider at least looking around at how others are doing it.
HTH
I do not consider your way to be safe. If I could listen on the wire and cache the request I will have the login an the password to the service. There even does not matter if the password is hashed or not. I like the point 3. in Eli Gassert's answer. It sounds very useful and light weight and you are not exposing the password because it is hashed "somewhere" in the request.
I am in the process of re-writing some very outdated .NET 2.0 SOAP web services for my company. So I am rewriting them using MVC3 RESTful. This method would simplify the usage of our services for our client base (over 500 clients using our current SOAP services) who are on multiple platforms and languages.
I am looking for a BETTER method of authorization for the RESTful services, than what the previous developer used for our .NET 2.0 SOAP web services (he basically just had the client pass in a GUID as a parameter and matched it in code behind).
I have looked into oAuth and I want to use it, HOWEVER, I have been told, from my superiors, that this method is TOO complicated for the "level" of clients that connect to our services and want me to find another simpler way for them to connect but still have authorization. Most of our clients have BASIC to no knowledge of programming (either we helped them get their connection setup OR they hired some kid to do it for them). This is another reason that the superiors want a different method, because we can't have all 500+ (plus 5-10 new clients a day) asking for help on how to implement oAuth.
So, is there another way to secure the MVC3 services other than passing a preset GUID?
I have looked into using Windows Authentication on the services site, but is this really logical for 500+ clients to use?
Is there an easy and secure method of authorizing multiple users on multiple platforms to use the MVC3 RESTful services that a end-client can implement very easily?
Thanks.
If you don't want anything too complicated, have a look at Basic HTTP Authentication. If you use it over SSL then it should be safe enough and also easy enough to implement for your clients. The Twitter API actually used this up until a few months ago when they switched to OAuth.
You want to distinguish between authentication and authorization. What you are looking for is authentication and indeed as Caps suggests, the easiest way may be to use HTTP BASIC authentication along with SSL to make the password is not compromised.
You could look into other means of authentication e.g. DIGEST or more advanced using ADFS or SAML (ADFS could be compelling since you're in .NET). Have a look at OpenID Connect too - it is strongly supported by Google and has great support.
Once you are done with that, you may want to consider authorization - if you need it that is - to control what a given client can do on a given resource / item / record. For that you can use claims-based authorization as provided in the .NET framework or if you need finer-grained authorization, look into XACML.
OAuth wouldn't really solve your issue since OAuth is about delegation of authorization i.e. I let Twitter write to my Facebook account on my behalf.
HTH