Currently, even with a custome theme, Keycloak exposes itself, eg. when an incomplete URL is called (error page) or when landing URLs are used.
What is the best practice to avoid this? Ideally, the OAuth2 solution should not be visible for users. Is this best implemented in the infrastructure level, on Keycloak Theme level or somewhere else?
Related
I'm looking for an API management system, that will intergrate with Keycloak (Keycloak should provide all of the authentication).
Wicked.io (kong based) looks nice.
I've tried adding oAuth2 as an auth method, but wicked keeps generating its own client ids and secrets.
Is there any way to do this with wicked?
wicked.haufe.io maintainer here.
Combining wicked/Kong with KeyCloak may not be a very good idea. Wicked solves a lot of the problems KeyCloak is intended to solve as well, and the overlap is quite big, e.g. doing identity federation (SAML, OAuth2) to an OAuth2 workflow and all that.
KeyCloak and wicked/Kong follow different principles though; KeyCloak issues tokens which are validated via a KeyCloak library inside your services. This more or less replaces the API Gateway - it's implemented inside your services, based on the KeyCloak library.
wicked/Kong as a contrast is built up differently, where the big differentiator is the API Portal wicked provides on top of Kong and that you have a dedicated API Gateway (Kong). Wicked provides you with its own client credentials, and it also wants to do the entire authentication and authorization bit. What you get in exchange for that is the self service API Portal; if you don't need that, you will probably not need wicked.
What you can do is to federate a KeyCloak OAuth2 flow into wicked, by having KeyCloak act either as a SAML or OAuth2 identity provider. You would then register your KeyCloak Authorization Server as an identity provider with wicked (using a single service provider (SAML) or client (OAuth2)). The "but" here is that you would still need to provide an entry point to your services which do not go via the KeyCloak library.
wicked/Kong always works like this: It takes away the need to implement Authentication/Authorization inside your services; instead you need to check for the headers X-Authenticated-UserId and X-Authenticated-Scope. With wicked, this will typically contain something like sub=<some id>, also depending on which type of identity provider(s) you have configured wicked to use. But this approach usually replaces KeyCloak. The upside is that you can have one single entry point to your services (=Kong), and you have a quite lightweight way how you can protect arbitrary services - not only services written in languages KeyCloak supports! - behind an API Gateway while providing self service access (with configurable plans, documentation,...) via an API Portal.
All these things are obviously somewhat complicated; wicked is extremely flexible in its usage, but it's not really meant to be combined with KeyCloak (which is likewise. It all boils down to really understanding the use case and finding a solution architecture which solves your use case in the best way.
If your use cases involve an API Portal and API documentation (it should), going wicked/Kong may be a good possibility. If it doesn't, you may be happier sticking to KeyCloak (which you can see as a headless API Management system with a decentralized gateway of you want).
Disclaimer: My knowledge on KeyCloak is somewhat outdated; it may be that there are updates which also go into the API Portal direction, but of this I am not aware.
Is PassportJS using Facebook Authentication enough for an iOS backend with Node JS?
I have the toobusy package as well to decline requests when things get to busy (I'm guessing it would be good for DDOSes).
I'm thinking of using nginx as a reverse proxy to my Node.JS server as well.
What are some more security measures that can scale? Some advice and tips? Anything security related that I should be concerned about that PassportJS's authenticated session can't handle?
It’s a bit hard to cram in all security-related best practices in one post, but for what it’s worth, here’s my take on the issue.
Providing authentication and securing it are two separate things. PassportJS will be able to handle everything related to authentication, but it’s an entirely different thing preventing it to be fooled or overwhelmed.
One (big) reason for putting PasswordJS behind a reverse proxy (RP) is that you’ll be able to provide a first line of defense for anything related to HTTP: header/body lengths/data, allowed methods, duplicate/unwanted headers, etc.
Nginx/Apache/HAProxy all provide excellent facilities to handle these cases and on the up-side, you get a nice separation of concerns as well: let the reverse proxy handle security and let PassportJS handle authentication. Architecture-wise, it will also make more sense because you’ll be able to hide the number and infrastructure of PassportJS nodes. Basically, you want to make it appear as there is only one entry point for your clients. Scaling out will also be easier with this architecture. As always, make sure that your RP(s) keep as little state as possible, preferably none, in order to scale linearly.
In order to configure your RP properly, you need to really understand what how PassportJS’ protocols (in case you want to provide more authentication methods than just Facebook’s) work. Knowing this, you can set up your RP(s) to:
Reject any disallowed request HTTP method (TRACE, OPTION, PUT, DELETE, etc).
Reject requests/headers/payload larger than a known size.
Load-balance your PassportJS nodes.
One thing to be on the lookout for in terms of load-balancing are sticky sessions. Some authenticators store all their state in an encrypted cookie, others will be a simple session handle, which only can be understood by the node that created the session. So unless you have session sharing enabled for the latter type (if you need PassportJS resilience), you need to configure your RP to handle sticky sessions. This should be the maximum amount of state they should handle. Configured correctly, this may even work if you need to restart an RP.
As you diligently pointed out, toobusy (or equivalent) should be in place to handle throttling. In my experience, HAProxy is bit easier to work with than the other RPs with regards to throttling, but toobusy should work fine too, especially if you are already familiar with it.
Another thing that may or may not be in your control is network partitioning. Obviously, the RPs need to be accessible, but they should act as relays for your PassportJS nodes. Best practice, if possible, is to put your authentication nodes on a separate network/DMZ from your backend servers, so that they cannot be directly reached other than through the RP. If compromised, they shouldn’t be able to be used as stepping stones to the backend/internal network.
As per Passport documentation:
"support authentication using a username and password, Facebook, Twitter, and more."
It is the middleware, with which provides the feasibility to integrate multiple type of security methodologies with NodeJS.
You should consider the purpose of the application, is it only supporting Facebook Authentication or custom register/login process. If it is providing second option, then in that case, it is better not to rely on authtoken of any social networking site like Facebook/Twitter or any other.
The better option is to create your own token like JWT token, and bind it with the user from multiple platforms. It will help you in extending the scope of your project to integrate other social networking sites.
Here is the link to integrate JWT in NodeJS.
https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
Similarly there are many other blogs and tutorials available in market to integrate JWT with NodeJS
I am just getting my feet wet with Angular, and am still struggling to find the best (best for "my" situation) solution for dealing with auth and authz. In terms of auth, I have seen many different examples of how to accomplish this all with the angularjs app. However, even after seeing all of these solutions I am leaning towards breaking things out so that the login page is not part of the SPA. Instead, it would be served up a via server side rendering framework. In my case it would be asp.net mvc but that is irrelevant - the concept is the same regardless of the tech.
So, when the app is first accessed the SPA component would be protected and only after authentication would it be served to the client. I feel like if you are serving up the SPA before auth, it's not truly secure. It also removes some of the complexity from the SPA in terms of login views and logic, etc which I like. In addition, I'm thinking I may even want to handle other non SPA related activities outside of the SPA. Right now I can only see a need for user/auth stuff but at least the door is left open if necessary.
Regarding authz, I really can't escape this in the SPA. Obviously the back end APIs will be secured, but for a better UX I still need some concept of roles in the SPA so I can check routes and also handle the visibility of UI components.
Is this approach one that others have used successfully? I'm interested in hearing any success stories, but also any arguments for why this might not be a good solution. FYI - my background is server side development, with heavy duty security requirements. That background makes the whole SPA concept tricky to swallow ;)
When using OAuth (2) I need a redirection endpoint in my application that the OAuth-offering service can redirect to, once I have been authenticated.
How do I handle this in a single page application? Of course, a redirect to the OAuth-offering service is not nice here, and it may not even be possible to redirect back.
I know that OAuth also supports a username / password based token generation. This works perfectly with an AJAX call, but requires my single page application to ask for a username and password.
How do you usually handle this?
Most of the time, a redirect is okay even for SPA because users don't like to put their X service credentials on any other website than X. An alternative will be to use an small popup window, you can check what Discourse does. IMHO a redirect is better than a popup.
Google Some providers support the resource owner flow which is what you described as sending username and password, but this is not nice. These are the problems I see:
Asking google credentials to users in your site will be a no-go for some users.
The resource owner flows need the client_secret too and this is something that you must NOT put in your client side javascript. If you instantiate the resource owner flow from your server-side application and your application is not in the same geographically region than the user, the user will get a warning "hey someone is trying to access with your credentials from India".
OAuth describes a client-side flow called implicit flow. Using this flow you don't need any interaction in your server-side and you don't need the client_secret. The OAuth provider redirects to your application with a "#access_token=xx". It is called implicit because you don't need to exchange authorization code per access token, you get an access_token directly.
Google implement the implicit flow, check: Using OAuth2 for Client-Side apps.
If you want to use the implicit flow with some provider that doesn't support it like Github, you can use an authentication broker like Auth0.
disclaimer: I work for Auth0.
What José F. Romaniello said is correct. However, your question is broad and thus I feel any offered conclusions are just generalities at this point.
Application state
For example, without knowing how complex your application state is at the time you want to let your users log in, nobody can know for sure if using a redirection is even practical at all. Consider that you might be willing to let the user log in very late in his workflow/application usage, at a point where your application holds state that you really don't want to serialize and save for no good reason. Let alone write code to rebuild it.
Note: You will see plenty of advice to simply ignore this on the web. This is because many people store most of the state of their application in server-side session storage and very little on their (thin) client. Sometimes by mistake, sometimes it really makes sense -- be sure it does for you if you choose to ignore it. If you're developing a thick client, it usually doesn't.
Popup dialogs
I realize that popups have a bad rep on the web because of all their misuses, but one has to consider good uses. In this case, they serve exactly the same purposes as trusted dialogs in other types of systems (think Windows UAC, fd.o polkit, etc). These interfaces all make themselves recognizable and use their underlying platform's features to make sure that they can't be spoofed and that input nor display can't be intercepted by the unprivileged application. The exact parallel is that the browser chrome and particularly the certificate padlock can't be spoofed, and that the single-origin policy prevents the application from accessing the popup's DOM. Interaction between the dialog (popup) and the application can happen using cross-document messaging or other techniques.
This is probably the optimal way, at least until the browsers somehow standardize privilege authorization, if they ever do. Even then, authorization processes for certain resource providers may not fit standardized practices, so flexible custom dialogs as we see today may just be necessary.
Same-window transitions
With this in mind, it's true that the aesthetics behind a popup are subjective. In the future, browsers might provide APIs to allow a document to be loaded on an existing window without unloading the existing document, then allow the new document to unload and restore the previous document. Whether the "hidden" application keeps running or is frozen (akin to how virtualization technologies can freeze processes) is another debate. This would allow the same procedure than what you get with popups. There is no proposal to do this that I know of.
Note: You can simulate this by somehow making all your application state easily serializable, and having a procedure that stores and restores it in/from local storage (or a remote server). You can then use old-school redirections. As implied in the beginning though, this is potentially very intrusive to the application code.
Tabs
Yet another alternative of course is to open a new tab instead, communicate with it exactly like you would a popup, then close it the same way.
On taking user credentials from the unprivileged application
Of course it can only work if your users trust you enough not to send the credentials to your server (or anywhere they don't want them to end up). If you open-source your code and do deterministic builds/minimization, it's theoretically possible for users to audit or have someone audit the code, then automatically verify that you didn't tamper with the runtime version -- thus gaining their trust. Tooling to do this on the web is nonexistent AFAIK.
That being said, sometimes you want to use OAuth with an identity provider under you control/authority/brand. In this case, this whole discussion is moot -- the user trusts you already.
Conclusion
In the end, it comes down to (1) how thick your client is, and (2) what you want the UX to be like.
OAuth2 has 4 flows a.k.a. grant types, each serving a specific purpose:
Authorization Code (the one you alluded to, which requires redirection)
Implicit
Client Credential
Resource Owner Password Credential
The short answer is: use Implicit flow.
Why? Choosing a flow or grant type relies on whether any part of your code can remain private, thus is capable of storing a secret key. If so, you can choose the most secure OAuth2 flow - Authorization Code, otherwise you will need to compromise on a less secure OAuth2 flow. e.g., for single-page application (SPA) that will be Implicit flow.
Client Credential flow only works if the web service and the user are the same entity, i.e., the web service serves only that specific user, while Resource Owner Password Credential flow is least secure and used as last resort since the user is required to give her social login credentials to the service.
To fully understand the difference between recommended Implicit flow and Authorization Code flow (the one that you alluded to and requires redirection), take a look at the flow side-by-side:
This diagram was taken from: https://blog.oauth.io/introduction-oauth2-flow-diagrams/
I'm using ASP.NET MVC and I am trying to separate a lot of my logic. Eventually, this application will be pretty big. It's basically a SaaS app that I need to allow for different kinds of clients to access. I have a two part question; the first deals with my general design and the second deals with how to utilize in ASP.NET MVC
Primarily, there will initially be an ASP.NET MVC "client" front-end and there will be a set of web-services for third parties to interact with (perhaps mobile, etc).
I realize I could have the ASP.NET MVC app interact just through the Web Service but I think that is unnecessary overhead.
So, I am creating an API that will essentially be a DLL that the Web App and the Web Services will utilize. The API consists of the main set of business logic and Data Transfer Objects, etc. (So, this includes methods like CreateCustomer, EditProduct, etc for example)
Also, my permissions requirements are a little complicated. I can't really use a straight Roles system as I need to have some fine-grained permissions (but all permissions are positive rights). So, I don't think I can really use the ASP.NET Roles/Membership system or if I can it seems like I'd be doing more work than rolling my own. I've used Membership before and for this one I think I'd rather roll my own.
Both the Web App and Web Services will need to keep security as a concern. So, my design is kind of like this:
Each method in the API will need to verify the security of the caller
In the Web App, each "page" ("action" in MVC speak) will also check the user's permissions (So, don't present the user with the "Add Customer" button if the user does not have that right but also whenever the API receives AddCustomer(), check the security too)
I think the Web Service really needs the checking in the DLL because it may not always be used in some kind of pre-authenticated context (like using Session/Cookies in a Web App); also having the security checks in the API means I don't really HAVE TO check it in other places if I'm on a mobile (say iPhone) and don't want to do all kinds of checking on the client
However, in the Web App I think there will be some duplication of work since the Web App checks the user's security before presenting the user with options, which is ok, but I was thinking of a way to avoid this duplication by allowing the Web App to tell the API not check the security; while the Web Service would always want security to be verified
Is this a good method? If not, what's better? If so, what's a good way of implementing this. I was thinking of doing this:
In the API, I would have two functions for each action:
// Here, "Credential" objects are just something I made up
public void AddCustomer(string customerName, Credential credential
, bool checkSecurity)
{
if(checkSecurity)
{
if(Has_Rights_To_Add_Customer(credential)) // made up for clarity
{
AddCustomer(customerName);
}
else
// throw an exception or somehow present an error
}
else
AddCustomer(customerName);
}
public void AddCustomer(string customerName)
{
// actual logic to add the customer into the DB or whatever
// Would it be good for this method to verify that the caller is the Web App
// through some method?
}
So, is this a good design or should I do something differently?
My next question is that clearly it doesn't seem like I can really use [Authorize ...] for determining if a user has the permissions to do something. In fact, one action might depend on a variety of permissions and the View might hide or show certain options depending on the permission.
What's the best way to do this? Should I have some kind of PermissionSet object that the user carries around throughout the Web App in Session or whatever and the MVC Action method would check if that user can use that Action and then the View will have some ViewData or whatever where it checks the various permissions to do Hide/Show?
What you propose will not work. Actions can be cached, and when they are, the action (and hence your home-rolled security) does not run. ASP.NET membership, however, still works, since the MVC caching is aware of it.
You need to work with ASP.NET membership instead of trying to reinvent it. You can, among other things:
Implement a custom membership provider or role provider.
Subtype AuthorizeAttribute and reimplement AuthorizeCore.
Use Microsoft Geneva/Windows Identity Foundation for claims-based access.
Also, I completely disagree with ChaosPandion, who suggests making structural changes in your code before profiling. Avoiding exceptions for "performance" reasons is absurd -- especially the idea that the mere potential to throw an exception for invalid users will somehow tank the performance for valid users. The slowest part of your code is likely elsewhere. Use a profiler to find the real performance issues instead of jumping on the latest micro-"optimization" fad.
The correct reason to avoid exceptions for authorizations is that the correct way to indicate an attempt at unauthorized access in a web app is to change the HTTP status code to 401 Unauthorized, not throwing an exception (which would return 500).
Define your authorisation requirements as a domain service so they are available to both the web and web service implementations.
Use an authorisation filter to perform your authorisation checks within the web application, this should be as simple as creating an auth request object and then passing it to your auth domain service.
If the authorisation fails, return the correct error - a 401 as indicated by Craig Stuntz.
ALWAYS authorise the action. If you can hide the link to unauthorised users - thats nice.
Simplify your views / view logic by writing a HtmlHelper extension method that can show / hide things based on a call to the auth domain service.
To use your authorisation service from the web service is simply a matter of constructing the auth request object from something passed in via the service message instead of from a cookie passed by the users browser.