I currently have an application running on our Windows Intranet consisting of a backend (Golang) and multiple frontends. Currently frontend users must authenticate to the backend using a password but we want to move to SSO (single sign-on) for improved security and user convenience. The frontend can use SPNEGO to negotiate IAW (Integrated Windows Authentication) which would allow the backend to know the Windows login ID of the frontend user.
I know how to configure the frontend (web browsers) for this and it would be handled automatically in the backend if I was using IIS for the web server. I just need the equivalent code for a Go web server.
https://github.com/jcmturner/gokrb5/v8 appears to support this but I have been unable to get it to work. There is some example code such as https://github.com/jcmturner/gokrb5/blob/master/examples/example-AD.go but I have not been able to understand how to adapt it to my needs. Does anyone have a working example?
Related
I have created a tenant and application to be able to authenticate users via Azure B2C. I have a front-end application in React which uses Msal.js with authorization grant to obtain the access token, which is then used to make requests to a webserver which acts as a resource-server (connected to Azure b2c as well). I have used this answer to make it work -> How to secure Spring Boot REST API with Azure AD B2C?
Apart from that I have few daemon applications which need to connect to the backend as well. They should use client_crendentials grant_type to connect to the backend server (which is a resource-server).
However, the token that is obtain by the daemon app, cannot be used with the backend server (resource server) for some reason. Is there something that I do wrong ? Do you have samples for this scenario ? I've already spent days looking over all the documentation to find where is the problem.
We're getting ready to rewrite an old native windows mobile application that accesses data through a VPN. We'd like the new version (.NET Windows 10 mobile application) to access data through web services that are protected by Okta. What is the best way to do this?
Thanks!
The best way to do this depends on how the web services are protected.
The main thing to keep in mind is that you don't want to store any secrets on the mobile application.
In an ideal world, these web services would be secured with something like OpenID Connect (OIDC), allowing you to authenticate against Okta (the "IDP") to get access to the web services (the "Relying Parties").
However, the real world is messy, where some web services are protected via SAML, OIDC, OAuth, custom headers, etc.
Without knowing more about your setup, my recommendation would be to build against OIDC, using a proxy server (or "API Gateway") as needed to secure your web services using OIDC.
One of my co-workers at Okta has written a sample iOS application in Xamarin that implements OIDC, I suggest taking a look at the ViewController.cs file in that repository.
We currently have an installation of IBM content navigator that we built a feature inside, this feature shows another web application installed on the same server inside an iFrame, this application connects to CPE using Java WS APIs to do some operations using the ICN logged in user credentials.
The main problem we are facing is that in our current solution the user logs in twice, once to log in to the ICN, and another to log in to the web application, which is undesirable and we need to eliminate this second login and implement some sort of SSO.
One option available is using Kerberos, however as it currently stands the FileNet Java api does not support Kerberos at the moment (only .Net).
Any ideas are much appreciated
References
Using Kerberos on an API Client - https://www.ibm.com/support/knowledgecenter/SSGLW6_5.2.1/com.ibm.p8.ce.dev.ce.doc/sec_procedures.htm
If your web application is deployed on the same WebSphere Cell, you don't need to use Kerberos. Kerberos need to support SSO between WAS and client only, not between application and client.
You don't need to use createSubject(), just get it from security context and provide it to CPE.
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.
We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).
How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?
Thanks a bunch!
EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.
Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).
You can do this with web server settings, or within the code of your REST APIs
I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.
For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.
You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.