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/
Related
I have an ASP.NET application hosted as Azure App Service. This application is configured with Microsoft Authentication. But the problem is anyone with hotmail/live account will be able to access the application.
I wanted to restrict the access to my Application Pages to SPECIFIC hotmail/live users only.
What changes I have to do on Azure Portal?
What changes I have to do in my application?
Thanks,
Paraclete
Applications typically have two "gates" of security - authentication and authorisation.
The simplest way would be to set up a list in a store (e.g. SQL DB - or hard code for testing) of authorised users. Let the Microsoft Authentication handle authentication and then use your list for authorisation. Redirect to HTTP Status code 403 forbidden if a user is not in the list of approved users.
You could make this a bit more fancy by implementing groups/roles, which is more elegant and manageable. Look in to the ASP.NET Role provider for built in functionality to expedite development. That said, some people find this build in approach cumbersome and roll their own simple provider and add it in to the page life cycle or the master page to share the functionality across all pages.
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.
I am going to have an ASP.net MVC web site (example.com) and a Web API site (api.example.com) running on the same domain. What is the best and most secure way to use Forms Authentication to allow a user to log in to the MVC site, and have that login accepted by the [Authorize] filter in the API site? Additionally, there is the possibility that both sites will be hosted on multiple servers (each of which might have its own subdomain), so a solution that would allow for a single sign on approach to work among all of the servers in the cluster would be preferred.
Take a look at this link http://www.codeproject.com/Articles/27576/Single-Sign-on-in-ASP-NET-and-Other-Platforms this covers the answer in detail.
You will need to ensure all machines and separate applications on the site share a common (but unique to production) machine key to allow the authentication cookies to be trusted by all the machines/applications.
If you are simply using virtual directories under the same sub domain then simply harmonising the web.conig Forms Auth settings and machine keys should get you up and running very quickly.
If you want this to work between a second level domain then you need to change the "Domain" setting on the Form's Auth cookie. See the article for details.
We have implemented several intranet web applications in my company. They all:
are built by ASP.NET MVC 3
use CAS(ticket in cookie policy) and a shared LADP server to single sign on
have role based access control logic according to current logon user
expose many RESTful(like) web apis for page's ajax usage
Now we find those web apis for ajax requests can be used as services for other web applications(like employee info, client info etc). Which means we need to access those apis at backend(with C# code). The problem is the authentication and authorization.
I don't know how to go with the existing authentication mode to access those web apis. I can only think of a way that use an shared service credential among back end servers but it means this credential must have a full access authority. Is it a security risk? And as I metioned, we use ticket in cookie policy with CAS. Which is OK for browser but seems difficult for C# code. How to use a credential with CAS from backend? Use a WebClient and handle 302 manually?
Has anyone met a similar case and have some good experiences with this? Please give me some advice. Thanks a lot.
What you need here is to use the CAS proxy mode to access backend web services : https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough.
I am putting a plan together for a series of sites that will share user account information among them. The idea is that once a user logs in using their OpenID, they can access any of the sites and it will know who they are.
What are the common patterns/best practices that i could employ to achieve this?
If all the sites share a common hostname in their URL then you can set an auth cookie (FormsAuthentication.SetAuthCookie) specifying the path of the cookie to be "/" so that all sites can see the user is logged in.
If the sites are not sharing a common host name, I think the only way to get a truly "once signed in, signed in everywhere [within your ring of web sites]" would be for all authentication to happen at just one site (perhaps one dedicated to authenticating the user) and for the other sites to redirect the user to that site for authentication and then that site would redirect back. In essence, that auth site becomes an identity provider, and almost exactly fills the role of an OpenID Provider (in fact DotNetOpenAuth could be used here for this exact purpose). Since it sounds like your goal is to let the user log in with their OpenID, your OpenID Provider on that one auth site could itself use OpenID to authenticate the user. Your own pure-delegation OpenID Provider could be written such that it always responds immediately to checkid_immediate requests as long as the Realm in the auth request is one of your trusted ring of sites. Thus you could effect single-sign-on across all your sites.
Please consider the following Patterns & Practices on Web Service Security from Microsoft:
Brokered Authentication - http://msdn.microsoft.com/en-us/library/aa480560.aspx
The main topic is - Web Service Security
Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0
http://msdn.microsoft.com/en-us/library/aa480545.aspx
Ultimately theres lots of ways you could do it. I achieved a simple single sign on by building a url with a token from one website pointing to another domain. The encoded & encrypted token contained details to submit back to the previous domain. Upon receiving an incoming request on the second domain, an underlying web service checks that the incoming request's token is valid with the previous domain using a shared private secret, known to both domains.