I have an ASP.NET SPA which is data driven by Web Api. It's using default login mechanisms at the moment. A future scenario is to do all communication from the web server to the backend over a queue (RabbitMQ).
Then the simplified structure would looks like this:
User logs on, data exchange is routed over the queue to a backend service. My question is now how make the backend aware if the requst is comming from an authenticated user?
I found the Thinktecture STS and for what I know at the moment it looks very interesting. At least the web authentication should be no issue. but for now it looks to me as there is always a browser or a WCF service needed to do the authentication by the examples shown. There are no plans to use WCF or Azure on our site.
Is it possible to transfer tokens the STS issued over a queue and let the consuming windows service be aware of what to do with these token?
You could do poor man's delegation:
http://www.cloudidentity.com/blog/2013/01/09/using-the-jwt-handler-for-implementing-poor-man-s-delegation-actas/
The other thing you can do is use WS-Trust in IdentityServer to get a delegation token for the backend service.
Related
I'm starting to write a few microservices that will have independent web clients, a centralized authentication and authorization service, and an organization service. The organization service will keep track of who belongs to what organization and what that organization has paid for. This will tell me who can access which web client and what parts of each individual microservice. I've only developed authentication using Devise in a single Rails monolith, so I'm exploring how to do it in a multi microservice and web client ecosystem. I've come up with this:
Web Client makes a request to a microservice and is denied because lack of session information sent in the request.
Web Client makes a login request to the Authentication service. The Authentication makes a request to the Organization service to see what organizations the user is a part of as well as the services paid for. The session info is stored in the Web Client for future use in requests.
Web Client makes a request to the Microservice. The Microservice validates the session information (from 2) against the Authentication service, which in turn reaches out to the Organization for the user's organizations and the organization's services. The response from Authentication is stored in the Microservice. The response back to the Web Client is granted if the two sets of session information match.
Web Client makes a request to the Microservice, including the session info (from 2). The Microservice validates the session info against the stored session info (from 3). The response back to the Web Client is granted if the two sets of session information match.
Is this the proper way to authenticate? Is there a better way to do it? Are there small tweaks I should make?
Additionally, should I treat Authentication from the Web Client to the Microservices differently than Authentication between Microservices?
Do yourself a huge favor, and don't try to invent this yourself. Many, many people have written a fully functional auth & auth system, and a few of them have done it right. Unless you are a security specialist (which you likely aren't if you are asking this question), use a framework.
Start by looking at OAuth 2.0 and OpenId Connect providers, it is the de-facto standard in distributed authentication. Whichever language/platform you are using, likely has an implementation that you can leverage out-of-the-box. This will dramatically speed you up, and will likely avoid all the things that you will be doing wrong in your implementation.
Here you are, ready out of the box, Identity Server based on Open ID and Auth2.0 that is all what you need.
welcome-to-identityserver4
If you were interested in the topic of Microservices Architecture the following links are a set of articles that published about microservices in code-project, you can read and comment on your questions if you like.
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-II
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-III
I have several web services that I want to make available to clients. My clients are split into two groups:
users using a web browser (I serve a web page that uses javascript + AJAX to request data from the web services)
applications (e.g. server app pulling data into a client's system)
1) I can solve the former by exposing my web services to external users using the application server and I can use the identity server to authenticate access (haven't worked how to do this out yet).
2) The latter is nicely satisfied by using the API manager. I can happily tell clients to log in to the API manager and subscribe to APIs. The APIs I create are proxies for the web services mentioned in 1).
I know that an API I create in the API manager can include a username and password for accessing the proxied web service. Is it possible to let an API proxy a web service that is authenticated using the identity manager? Sorry I'm reading documentation and struggling to understand if I can do this. Thanks
". Is it possible to let an API proxy a web service that is
authenticated using the identity manager? "
Currently APIManager supports the service endpoints which are secured using basicauth/usernametoken.
If you use identityserver to secure you service, using any other mechanism, that wont be supported by APIManager.
Stodge,
Default API manager authentication mechanism is Oauth. it uses Oauth token mechanism to authenticate all APIs.
Please refer [1],
Here the authentication component also sits in the AM. This can be delegated to a different AM instance if required.
Hope this helps.
[1] http://docs.wso2.org/wiki/display/AM140/Token+APIs
I have a WCF service that uses UserName authentication via ACS. This works great when I'm using Service Identities but when I try to use my Windows Live ID credentials I get the following error:
System.ServiceModel.FaultException: ACS10002: An error occurred while processing the SOAP body. ACS50012: Authentication failed. ACS50026: Principal with name 'louis#arsunica.com' is not a known principal.
Unfortunately I've yet to find an example of how one uses Windows Live ID with a WCF service. The only examples I could find seem to be focused on integrating multiple identity providers with ASP.NET or MVC websites.
Any help in this regard would be greatly appreciated....
ACS won't authenticate your Live ID username and password directly. ACS acts as a federation provider for Live ID, it's a go-between, so it will only consume tokens issued by Windows Live ID. ACS supports Live ID authentication out of the box in passive (browser redirect) based scenarios but for a WCF service you might consider using Live Connect APIs instead.
To use LiveID with your service, your client first authenticates itself to LiveID, and then presents a LiveID-issued token to your WCF service. Brace yourself though, there would be some hoops to jump through to set all of this up.
To use the Live Connect APIs, you would register your WCF service as an application with Live ID. Clients that consume your WCF service would then need to be capable of handling the web based login page and user consent pages that Live ID will prompt. The docs below are a good start
http://msdn.microsoft.com/en-us/library/hh243641.aspx
http://msdn.microsoft.com/en-us/library/hh243647.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/hh465098.aspx
The next problem is the token you'll get from Live Connect will be in JWT (JSON Web Token) format. I'm not sure if you can request a different token format from live connect, but if your WCF service authentication is WIF based, it most likely expects SAML tokens. JWT is a rather new token format that WIF doesn't yet support so you would have to configure a WIF SecurityTokenHandler on your service that understands JWT tokens. The third link above has some code for reading JWTs, which is a start at least.
I have several Silverlight, WP7 and ASP.NET MVC client applications Most allow anonymous access to the application but secure various features based on a user's credentials when logged in. All of the clients use a common back-end service application for data access and business processing which require the user's credentials for authentication and authorization.
We currently use Forms Authentication in all client applications and I'd like to migrate our architecture to use federated identity and a claims-based model. Passive federation is not an option.
I am looking for the following flow:
The user triggers the login dialog, enters their username and
password then clicks "OK".
Behind-the-scenes, the application calls an active STS service in
our existing service application for authentication.
The service is actually a federated STS and passes the call through
to the (active) IP_STS which may or may not be ADFS.
When the IP returns the token to the FP, the FP modifies the token
with additional claims from the server data store before returning
the token to the client application.
The client application maintains the token in memory for
authorization checks (in Thread.CurrentPrincipal, for example).
The client also passes the token when making requests to other
service operations in our service application.
These service operations will use the token to
authenticate/authorize the request.
This is a very different use-case from any of the articles and samples I've been able to locate. Can anyone provide some guidance and/or point me in the right direction?
It is my understanding from Dominic Baier that WIF doesn't currently support the approach we are taking. We've taken his suggestion and created our own custom STS that moderates authentication using the Provider model.
Unfortunately, the farther we got into this, the more we realized that WIF isn't flexible enough to satisfy our needs at this point. We stuck with the custom STS approach but are using our own transport and credentialling rather than the WIF tooling. Hopefully a future release will give us what we want.
I'm rather new to SOA and therefore experimenting around.
Currently, the part that creates the biggest problem to me is authentication, my current thought about it involves the following:
The client sends some kind of authentication message to the authentication / user service, this service queries the db and if the user is found and the password is valid, it will respond with a session id, this id will be used in all further requests of this client.
This seems rather ok to me but I don't know how I should handle the requests to other services, I thought of three different approaches.
Every service asks the authentication service if the session is valid and if so, what roles the user is in. The authentication service looks in the db and replies accordingly.
The authentication service keeps all session information in ram and responds without the db roundtrip to the requests.
The authentication service sends an authorized message to an esb, the esb forwards this authorized message to every service and these services cache it. No further requests to the authentication service would be necessary. If the user logs out or his roles change, another message would be send around and processed by all services.
I think the first approach creates too much stress on the authentication service / db but takes the least effort to implement.
The second is still very easy to implement but the stress on the authentication service remains almost the same.
The third is a little more complicated to implement but would has reduced response time as no trips to the authentication service take place. Though, if there are too much session information this approach would just fail and scalability is hardly given.
The best approach should be like this if all the services are internal,
The authentication service issues a token the the service client.
Service client includes the token in the SOA message wrapped in WS-Security or something similar.
The service should validate the token with authentication service before providing the service.
For external services, I suggest you look at federated solutions like SAML.
Don't do premature optimization. Your option no. 3 which you acknowledge will be more complicated to implement is unnecessary. Choose option no. 2 if that's what you can implement fast. You can profile later and change it, but I'd bet money that you won't have a 'bottleneck' when going with option 2.