I recently read about Kerberos and its great algorithm to securely authenticate user.
But the "drawback" of Kerberos is that it requires credentials (calls "principals") to be added manually directly from the authentication server (implemented with Kerberos so).
So, unless I ignore it, it's impossible to use a classic form in an e-commerce to add a NEW user to Kerberos. Indeed, obviously, it will waste Kerberos principle because credentials would be sent over the network, even if they are encrypted with SSL...
Could you confirm me or not that Kerberos cannot be use for classical Web Site requiring each user to create themselves adding their own login/pass? That means without need of Kerberos server's administrator.
You can, in terms of technical capabilities, use Kerberos as the backing store for authentication information and still support username and password over SSL. It's not the ideal Kerberos model, since it means that a system other than the local system the user is sitting in front of gets a copy of the password. But that just means that you're not using the full security capabilities of Kerberos; it doesn't mean that Kerberos won't work. It may still be convenient to use Kerberos for other reasons.
One of the dirty little secrets of Kerberos is that nearly every site that has deployed it on a large-scale basis accepts username and password over SSL for at least some applications and validates the username and password on the server. There just isn't any other good way to do it in a lot of cases. This is particularly true of web applications. While many web browsers do support SPNEGO via Negotiate-Auth to do a real Kerberos authentication, this doesn't work in a wide variety of situations (no Kerberos locally on the system, kiosk system, phone device with no local Kerberos libraries, etc.).
(I'm the Kerberos administrator for Stanford University and also the maintainer of our web authentication system, which is based on Kerberos but still, for most users, takes username and password over SSL and verifies them on a central web login server.)
Related
We have 2 web applications in production since several years. They are currently only accessible from the intranet of the company. Future changes in the company's organization require to make these applications accessible from the internet. It is planned to use Okta to reinforce security. I don't know nothing about Okta yet. As far as possible, the changes should have as little impact as possible.
Current situation:
Web App 1:
ASP.NET MVC solution secured with userid/password ASP.NET Membership with forms authentication. Userid is an internal user code like ADE465 for example.
Web App 2:
ASP.NET MVC solution secured with userid/password authentication through IdentityServer2 (Thinktecture). Userid is firstname dot lastname like john.doe for example.
All web apps are hosted on IIS on an Azure virtual machine named (let's say) FABVM03.
For the future Okta integration: no need to have SSO (Single Sign On). Would it be possible to simply secure with Okta everything accessed on the server FABVM03? Or everything accessed from a specific URL ?
For example, if someone tries to access https://example.com/webapp1/login.html Okta should comes up and ask for authentication (Okta verify) and if successful allow the user to access the requested url. In fact, the 'already in place' login/password should then be asked as it is already the case. I agree the user would have to enter credentials 2 times: first for Okta verify, next for login the specific web application. But that's okay. As you will have understood, no code modification in the web apps would be necessary in this scenario.
My question is to know if something like that is possible with Okta. If not what is the less impacting possible solution with Okta ?
Okta is not to enforce your policies (PEP), it's mainly SSO and Access Management solution.
Okta has a component, called OAG (Okta Access Gateway), which can be used to reverse-proxy your on-prem applications (which will work in your situation too, as your VPC is effectively equal to "on-prem in a cloud"). Which can do something like you want (protect your application and ask for authentication/authorization), but it's an additional package on top of basic Okta costs.
What you may need is a level of protection added on Azure Network layer, not sure if there is something like that though. I've seen some modules for nginx, capable of intercepting traffic and redirecting it to Okta, if not accompanied with a token. So try to dig into these 2 directions...
You need some proxy-based solution to talk to Okta and enforce the protection for your applications. There are open source tools:
https://github.com/vouch/vouch-proxy
https://github.com/oauth2-proxy/oauth2-proxy
https://github.com/buzzfeed/sso
Or you can checkout some commercial tools:
https://www.okta.com/products/access-gateway/
https://www.datawiza.com/platform/
I have used spring security in the past and understand that most of the features of keycloak can be achieved by using spring security ( ldap integration etc ).
Apart from easy social media login validation, are there any other unique features in key cloak which cannot be done using spring security?
With spring-security you would have to create Spring authentication server and explicitly configure/code certain things for integration with LDAP, OAuth2/OIDC providers.
Keycloak is already OAuth2/OIDC/SAMPL compliant IAM provider. It provides features like User Federation with options like LDAP, integration with other OIDC provider etc.
Keycloak provides SPI integration points where you can customize the request flow, use OTP, perform two factor authentication, add google CAPTCHA, or even your CAPTCHA. It provides role based authorization too if you need.
It also provides event handling integration points for events like Login, logout, refresh token, etc.
Keycloak Community will keep adding new features or keep supporting it w.r.t. changes in OAuth2, OIDC, SAML. You don't need to worry about updating your code time to time. Along with this, security updates will be there.
There are many more features.
Most importantly, why reinvent the wheel, if you get these many features and good support.
Keycloak allows you:
to use multiple user storage and get users from multiple LDAP/AD or Kerberos or use without any LDAP.
to login once (SSO) and forget about to login from another application with GUI;
to use one authorization server for multiple application by separation them by realms. One thing should be noted: keycloak could be installed on multiple nodes for better reliability; This also could helpful when application become big and once you decide to separate it on multiple.
to add user additional attributes and fields during get user info without coding (trivial example - set phone number) or specific roles (on realm or even client level) or groups and use all this on the top of an AD attributes;
to configure password rules like password expiration, e-mail validation and so on;
to set up 2-factor authorization with SMS or Email.
These things I think could be implemented using Spring Security, but it takes more time than Keycloak installation and configuration. Personally, I am using Keycloak in multiple commercial projects and could claim that Keycloak is good.
I believe the short answer to my question is "No", but allow me to describe the context.
We are currently using IdentityServer to authorize access to our APIs (via client credentials). All of the API clients are computer programs which run in our data centers and are under our control. In order to minimize our attack surface, our IdentityServer is running from an internal/private network, reachable from our APIs, services, and other apps. No problems.
We now want to leverage the IdentityServer installation to provide user authentication for our public-facing web applications. These applications run via ASP.NET MVC and will consequently require user interaction with the IdentityServer for password validation (implicit or hybrid grant type). This appears to be a hard requirement, but I'm curious if there is a simple way to maintain the private installation of IdentityServer.
Can we proxy requests from the ASP.NET middle-ware for handling the authentication handshake, and does it even make sense to do so? I'm leaning towards a public-facing STS to eliminate any proxying, but thought I would ask to see what other patterns are employable.
For what its worth, we would ultimately use cookie-based authentication with the hybrid flow, but would be able to start with the implicit flow too.
The user's browser must be able to access the identity server. This can be via a proxy though.
For each Asp.net MVC application we use Static or Dynamic Key to Validate user Requests/Responses for example in web.config file we may use this due to have static validation :
<machineKey validationKey="AC7308C5274D969E665AC7BED7A863582B571D97D9ED03B314952BD3DD159CDFC164E2341D44BDE8F0284FA924052817B3D7429433AABC3F53A118BB7B3F9ABB" decryptionKey="1EDB4490EC0074F7FF3099D450D5E92F1D39F577F9799D14033D1B27DB0F7A93B" validation="SHA1" decryption="AES" />
At the other hand we have a tool, named SSL (Secure Socket Layer) to upgrade Web App security. SSL also have non repudiation mechanism.
With this in mind, My Question is :
What differences exist between
them? And What types of jobs are related to them? Each one Will secure
which part of App? In other words: Can we be confident from our app by using MVC ValidationKey instead of using SSL?
The concept that baffles me is : They have both Encryption/Decryption.
The very high level answer is that they protect different things. They're complementary; secure ASP.NET applications use both of them at the same time.
SSL is used to protect the client and the server from an untrusted third party. It provides authentication: the client knows the identity of the server he is talking to. It also provides integrity protection: the client knows the page he's getting actually came from the server instead of an attacker. And it provides confidentiality: nobody can read the credit card number the client sends to the server during checkout.
The <machineKey> element, on the other hand, protects the server from a malicious client. Consider that your server sends me a login cookie that says "levi". What if I change the cookie contents to instead read "amir"? The <machineKey> cryptographic services allow the server to verify that when information like cookies and form fields (__VIEWSTATE, for instance) are round-tripped from server -> client -> server, the client hasn't tampered with the payload in a malicious fashion.
UPDATE: I failed to mention earlier that we want solution that will be flexible with authenticating users from within our databases or by asking other servers to tell us if the user is authenticated. It is also worth mentioning that these other servers are not under our control so we can't enforce a specific user model.
I had a long and hard read on OAuth and OpenID but they are both not a suitable solution for our situation and will make the process harder to the user. This is something that has been solved a thousand times, yet I cannot find the solution.
What we are looking for is a framework that can be used in a REST services server to authenticate users (no third-party clients involved) with their username and password.
The solution must not pass the username and password except the first time on login and use tokens for further authentication. Even though OAuth does use tokens, it is designed to allow third-party clients access to the service-providers resources. That is not the case here, the services are for our own application only, the only thing needed is user authentication.
What do you guys think is the most appropriate solution?
Configuration:
-Spring server that provides RESTful services with our thinking going towards using Spring Security with some user management and token management framework.
-iOS Device that will be making HTTPS calls to the server.
What we ultimately want is to have the device send a login request and receive a token if the login was successful, later on make requests using that token. Just like Facebook, excluding third-party involvement.
Is there something that is ready to be configured in our server? Or should we consider building our own token management, comparison and generation software?
Is using Spring-Security with an iOS application without involving storing cookies or redirecting to pages possible?
OpenStack offers as part of it's many projects related to open source cloud... the project Keystone. Which does this pretty much exactly what you want.
You might want to check it out here:
http://docs.openstack.org/developer/keystone/