The main idea:
I have windows application (maybe IIS site, maybe standalone) that
natively accepts Kerberos authentication and impersonates user.
Kerberos token sent by client to app already has information about
user's groups SIDs, user's SID, etc.
On each request, from
HttpContext.Current.User I get information about user's groups'
SIDs, user SID, translate it to 'plaintext' and pass to non-windows
backend (as header, for example).
Backend (which can not do kerberos)
can read claims added by App from proxied request and send answer, which will be
passed to app and then to user (backend->app->user)
Well, what's wrong with this concept?
Why I can not find any existing apps that can work similar way?
The only thing I found is FASTCGI\CGI, which sets REMOTE_USER variable, but this is not enough - frontend had Kerberos with huge amount of data which is dropped by the way to backend.
Related
I'm currently working on a project with complex requirements and I do not feel comfortable with the solution I'm considering.
The main idea is to secure existing applications (which do not include security themselves) without modifying them. These applications are not accessible from outside and will be accessible only through a reverse proxy (OpenResty).
Users do not have access to all applications and the solution to identify users is Keycloak.
The main components are :
An angular portal : the entry point
A reverse proxy that redirect the user on the chosen application
The IAM : Keycloak
All the available application
this schema explain it
The idea is :
The user click sign in on Keycloak and gets back to the portal with an access token (JWT) that contains his roles (application he has access to)
The user click on an application on the portal and he is redirected to the targeted application through the reverse proxy
The reverse proxy check the validity of the token (exp, iss and the roles)
I know this is not a proper way to do some SSO between application, but the requirement here is that the application, that are not secured can't be edited bu have to be protect by an upfront system (the reverse-proxy here)
My question is : ok this will work for the first call, because the user have his JWT token on the portal and hits the application with it the first time, but after when the user will click on a link in this app.. there is no more token. This kind of architecture works well to protect REST API bu for a web application, sounds to me a little incertain.
Generally, you would have reverse proxy server to handle user authentication instead of login to keycloak first.
Flow will be like this:
User access portal.
Portal redirects user to application through reverse proxy.
The reverse proxy will first redirect user to keycloak for
authentication, and build a security session between browser and
reverse proxy server.
The reverse proxy forward request to your application
server.
For all subsequent requests, user always go through reverse proxy server.
Try to use github.com/gambol99/keycloak-proxy. It stores token in the cookie, which is better option for web apps.
!!! Warning: I guess any auth proxy can use only Authorization Code Flow, however Implicit Flow is recommended for Single-Page Application (Angular). It really depends what's your Angular app. Analyze sec. pros and cons first, to be secure.
I'm working on a security setup suitable for the following client/server scenario, and I'm having a couple of questions/considerations that I'd like to share with you.
Situation:
I have a number clients on different platforms:
HTML-client (single page apps (SPAs) using jQuery/AJAX)
Android-app
Silverlight client
Windows client
Windows Mobile client
The large majority of the corresponding server components are based on .NET WCF using REST (but for some backends, I'm using other protocols).
I've found the open source project IdentityServer v2 from ThinkTecture to be a nice and flexible security token service (STS) for my solution. It supports a number of token types, protocols and is highly extendable and has a self contained Identity Provider (IdP) based on ASP.NET Membership database if needed.
The basic flow for clients using usernames/passwords is as follows:
The client makes an unauthorized HTTP call to a ressource (that requires authorized access) on its server
As the client is not yet authenticated, the server returns a HTTP 401 (unauthorized) providing an address to the STS in an HTTP Location header (see note on this below)
The client submits its credentials to the STS in a HTTP Basic Auth header
The STS returns a JWT token containing all relevant user claims
The client now repeats its initial request from step 1 including the JWT token in the HTTP Auth Bearer header
The server validates the token, as it originates from a trusted STS source, and returns the requested ressource
I know that step #2 is a bit unorthodox in combining the HTTP 401 error message with a HTTP Location header normally associated with the HTTP 3xx status codes. I need the 401 status code because of my jQuery/AJAX clients which handle the 302 redirect message automatically without any chance to interscept the redirect.
Now, the system needs to use an external IdP. The "internal" STS is customized to forward auth requests to the external IdP handling transformation of claims from the external IdP format to the internal format. One catch with this is that it implies the "password anti-pattern", but for now all systems are interal and trustworthly.
Could WS Federation be my friend?
The above basic flow applies to at all clients, browser based or not. But for specifically browser clients, I've been looking into a federated security scenario, having the resulting IdP/STS to provide a login mechanism for the clients. The STS that I use (IdentityServer) can be configured to be used in conjunction with a WS-Federation compliant STS. Thereby tokens are automatically transferred to the target token format (in my case for instance from the external STS's SAML token to the internal JWT token).
With this I can have some sort of a SSO mechanism.
Now my questions:
Is my described basic security flow optimal?
Is WS-Federation only applicable for browser clients?
If not, how can it be used with for instance my android clients?
In WS-Federation with more STSs, how is the communication flow between: client - internal STS - external STS (in terms of HTTP communication, cookies and stuff).
I don't think what you describe is WS-Fed. WS-Fed never involves 401 and never involves authentication headers.
WS-Fed has two versions, passive and active.
Passive is for browsers. It consist in 302 to the identity provider which in turn POSTs the SAML token back to the caller. The authenticaiton is then supported by cookies.
Active is for active clients (applications). It consist in a SOAP response that instructs the caller to go to the identity provider for the token. The SOAP response from the identity provider contains a token which is then supplied to the service.
What I believe is that the active scenario is quite complicated if your client doesn't support the WCF federation authentication binding (wsTrustFeb2005). You'd have to implement the flow on your own.
What I'd like to recommend instead would be the OAuth2 flow. OAuth2 has 4 different flows, of which two correspond to WS-Federation's active and passive: authorization code flow is for browser-based apps and the implicit flow is for desktop/mobile applications.
http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#authorization
OAuth2 integrates easily with WebAPI services and there is a great support for it in the DotnetOpenAuth library.
This and other authentication/authorization options are described in great detail in the Pro ASP.NET WebAPI Security book
http://www.amazon.com/Pro-ASP-NET-Web-API-Security/dp/1430257822
Even if you are not planning to build your backend around WebAPIs (but rather RESTful WCF as you mention), the book will give you necessary background on OAuth2.
On the other hand, if you still insist on WS-Federation, this free e-book describes both active and passive scenarios:
http://msdn.microsoft.com/en-us/library/ff423674.aspx
I created an iWidget for IBM Connections, which has to retrieve data from our external web application through the provided proxy. However, said application requires the user to be authenticated before providing an answer.
Is there any general recommendation on how to solve this? I'm aware that I can get the current user from the iScope of the widget, but just forwarding this information to our application is not secure - since everyone could just create such a request, pretending to be any user. I also know that the proxy can be configured to forward ltpa credentials, but I dont know how to validate such a token - maybe IBM provides a library for this task, that I'm just not aware of?
Suppose you have an app that uses a proprietary authentication system based on HTTP headers and further suppose that the authentication info is hard-coded into the app (I don't know how you would do it otherwise). It hits a web service via SSL.
I do not think that it would be possible to sniff out the headers (correct me if I am wrong) but would it be practically possible for a motivated user to decompile the app and get the API key somehow? How does this vary between iOS (Obj-C) and Android/Blackberry (Java)?
I have a main website running on AppEngine. It's on a subdomain like main.example.com. This main application is a content portal for our customers. It offers an Ajax application built on YUI. Customers can upload data to it. Users authenticate using Federated Login.
The Ajax application on it allows users to process the data previously uploaded. To do it it should use an webservice running on other subdomain like service.example.com. The webservice does not run on AppEngine but on our services - it's CPU heavy and built on other set of technologies. It would need to download the data on main application - but the downloading service - like everything on the main application - is behind the authentication wall.
I could programatically always allow the service to download wharever it wishes but I think this can turn into a major security problem.
How can I reuse the OpenID authentication "token" to allow it (the service) to appears to the main application as the authenticated user so it can download data? Or If I can do this what would be the best way to accomplish what I intend to do?
You can't really reuse the authentication token. What you should use is something akin to OAuth, though since you control both ends you can make it somewhat simpler:
Generate a shared secret, accessible by both main.example.com and service.example.com
When a user accesses service.example.com for the first time (no authentication cookie), redirect them to main.example.com/auth?continue=original_url (where original_url is the URL they attempted to access)
When you receive a request to main.example.com/auth, first log the user in the regular way (if they're not already). Then, take their user ID or other relevant credentials, and generate an HMAC from them, using the shared secret you established in step 1. Redirect the user to service.example.com/finish_auth, passing the computed HMAC, the authentication details such as user ID, and any parameters you were passed in such as the continue URL.
When you receive a request to service.example.com/finish_auth, compute the HMAC as above, and check it matches the passed in one. If it does, you know the request is a legitimate one. Set an authentication cookie on service.example.com containing any relevant details, and redirect the user back to their original URL.
This sounds complicated, but it's fairly straightforward in implementation. This is a standard way to 'pass' credentials between mutually trusting systems, and it's not unlike what a lot of SSO systems use.