What is a recommended authentication architecture for a front GUI app that I want to control but that will be used by others to control their servers?

I have a front end (WEB GUI) app that I designed (Python for now + JavaScript in the future) that I use to access a controller, it uses REST APIs.

I want to publish this app in the cloud so that others could use it.

The biggest issue I am seeing is the security side as the app needs to authenticate with the remote server (a controller itself) and start sending tasks to the controller that will translate that in internal REST APIs to control for processes on downstream servers

Is there an authentication flow that will guarantee the owners of the controllers that I (the publisher of the front end) do not intercept the authentication flow and I gain unwanted access to their servers ?

My idea is to use a two steps authentication/authorization process like below. Is there a better way?
Please edit this diagram if you have suggestions
enter image description here

Go to Source
Author: MiniMe

How to add a new listener on a new port and restrict it to one instance only

I am running oracle 11.2.3 and we have a server with multiple instances running. All of them are registered to port 1521 with the default listener. Now we are required to make one instance available on a new port. I was wondering if there is a way to add a new listener to a new port and restrict it to register only one instance so that this listener can not make connections for other instances.

Go to Source
Author: user211005

ASP.NET Identity using only Active Directory

We have an existing ASP.NET web app that is using Microsoft.AspNet.Identity framework. The previous developer wrote the code for this and unfortunately I don’t have much experience with it. It currently allows users to create an account on our app and that gets saved to the AspNetUsers table. I’m assuming that’s the default way accounts are stored with this framework.

This has been working well so far, but we want to expand our functionality in a way that we think would be better if accounts were stored in Active Directory. Ideally users would have a single login that would allow the following:

  • Login to our web app.
  • Ability to change password via the web app.
  • Log into SQL Server Reporting Services portal.
  • Log into SSRS server when building reports in Report Builder.
  • Provide database access as follows:
    • Only be able to see and SELECT from a handful of views.
    • These views would be able to filter data based on the user.
    • There would be groups that the user belongs to. Each group has ownership of a schema in the database. Members of the group would have full access to that schema.

With the current AspNetUsers table implementation, users can create accounts, login and reset password. For the SSRS functionality we’ve been creating a separate user in AD manually. So at this point, the user has two accounts to deal with, though they could use the same username/password so that it seems like one.

On the database access it is a little complicated, but seems to work:

  1. First, our users belong to one or more “Organizations”. And really that’s pretty much like a group, but it doesn’t use any kind of built in group functionality. We basically have an Organizations table in the database and then an OrganizationUser table that links AspNetUsers to Organizations.

  2. Each Organization has a Data Source in SSRS. Depending on what Organization the user is writing reports for, they will choose the appropriate Data Source. Organizations have corresponding local DB logins and that is the login used by the SSRS Data Source.

  3. On the database itself, the Organization login has ownership of it’s own schema. The schema is there so that users can store and retrieve tables of their own design. This is mainly for pre-computing of data for use in reports. The login also has access to a few views in the dbo schema. Those views utilize the DB login to determine what Organization it’s dealing with. That’s used to filter out any data that is “owned” by an AspNetUser entry that isn’t linked to the Organization.

As you can see, we also end up with a third Organization login on the database which is not really ideal either. Plus, we’re also seeing a need to have a user-level login because we also want to add a database view that only shows the users data rather than the data for the entire Organization.

I should also mention that I’d really like if, when a user creates an account, it gets created in AD rather than the database. I haven’t been able to find an example of being able to do this. There seems to be a lot of examples on how to login to AD, but not to create the account in the first place. I suppose I could keep the existing AspNetUsers implementation and write some AD code alongside all the existing endpoint code, however that seems like a waste if there was some way to just do it all in AD.

I was going to post in StackOverflow to see if anyone could help me on getting Microsoft.AspNet.Indentity to create users in AD, but I decided it might be a good idea to get some feedback on this design before I go down that route as I’m wondering whether it’s a good idea or not.

I know one of the concerns my co-worker brought up was getting too many accounts in AD. I don’t think it’s a big issue. This isn’t the type of application that would have a lot of users. His other concern was getting tied too close to a Microsoft stack, but I don’t think that’s a big problem either.

Go to Source
Author: Dan

How to protect secrets whilst enabling the ability to amend a pipeline

I’m writing a CI pipeline using GitHub Actions.

The pipeline will build a Docker image, which it will then push to our Docker repository (AWS ECR).

In order to talk to ECR, we’ll need to provide a secret (and some other details).

That secret we’ll be pulling from Hashicorp Vault… though that itself requires a secret in order to access it, so to some extent we’re just offsetting the problem.

The pipeline’s code is in the same repository as the code for which it is run (to which our developers have access); though we can hold some actions called by this code in a separate repository (to which only our DevOps team have access) if needed.

Whilst we trust our developers, it’s generally good practice to keep things locked down where possible. As such, is there any way we can set things up such that developers can amend the pipeline without being able to (deliberately or otherwise) expose these secrets? Are there any best practices around this sort of thing?

Go to Source
Author: JohnLBevan