There is a scenario like in the picture. There is a common database. Customers are connecting to the same database. After the connection, company-specific information is kept in a separate database. The connecting string is pulled from the company information in the database after the user logs in. How can I do this logic in .net core. I'm new and need ideas.
Click to see the script
When the user logs in, company information is also taken as in the picture.
Click for user company information
I can't define it in the "startup.cs" file because the user needs to be logged in.
Where and how can I define the connecting clause? Can you give an idea?
Startup.cs file
appsettings.json file
login method
In the login method, I need to migrate first. To create the tables. If there are tables, I need to connect to the company's product table. Can this special link be added to swagger too?
Specifically within .net core project you can utilise DBFactoryBase class, and create a constructor which accept appsettings json key to fetch another connection string.
I have an Access 2010 database with linked tables that connect to a sql server database. I do not have the connections set as a trusted connection, instead I want the linked tables to connect to the sql server login and password I provide. For users who are accessing this over our network it is still prompting for the password even though it displays the login id. Is there a way to make Access save the password as well in Access?
I found that in order to save a password in the DSN, I had to create a File DSN and in that file I had to be sure to include a field for the password such as:
PWD=mypassword
But there is a risk of exposing the password in a file. Ultimately, we decided that it was better to make users enter the password, which will be prompted for on just the first time they try to get a result from a query or table after they open the Access database file.
I am wondering what would be the best practice to logging when a user inserts or updates some data from my ASP.NET application.
In my application I need to know which user made the change, I think I have to options:
Register my ASP.NET users into the SQL Server adding them the rights for the tables needed, and store for each of my users
individual connectionstring. Thus I could use the currently logged in
user's connectionstring when connecting to the database, so that I
could write T-SQL triggers for SELECT and UPDATE.
The other option I thought of is that I can write stored procedures that get the ASP.NET user name as input parameter and makes
the log for me, (I use only one connectionstring in the application).
After modifying the database from the application I would call this
procedure giving the currently logged in user's username.
The second option seems simpler to me, but I think that for that purpose I should choose the first option.
Go for the second option. Managing users in a database creates more of a headache for you and what happens if you have to move the database server? You would need to update all of the connection strings for all the users. It just creates an extra admin overhead.
Furthermore, if you need to log all the changes in the database then I have come up with something that I have used in the past to store all changes made to a database over time. Have a look, it might be useful.
http://richhooper.wordpress.com/2012/06/11/sql-server-row-level-versioning/
So, I've gotten weary with trying to search for my problem online.
I am currently creating an ASP.NET 2.0 application. The application currently is connected to a database which stores all the information I need to store. I also have connection to the LDAP directory at my workplace on it. I am using the LDAP directory for my application as everything is tracked by employee ids. I now need to add authentication and authorization.
Since my workplace is large, I need the ability to limit who has access to the website within the company as well as what they are allowed to do on the website. I know that ASP.NET has some sort of authentication and authorization, but I am completely oblivious as to how it works.
My current solution is to add a table to my database with two columns (employee id and access_id). The employee id can be used to pull information from LDAP about the employee whenever I need to. The access_id is a set of integers that represent what the user is allowed to see on the website.
When the user first starts a session on my website I use their nt id and pull the employee id from LDAP. I then look up all the access_id's and store them in an array for the session. Everytime a user accesses part of the website, I check whether they have the access_id associated with that section and allow or disallow them based on that. My first access_id of 1 allows the user to see the webpage by setting the visibility of in C# as
if(access_id == 1)
Enter.visible = true;.
What kind of LDAP directory are you using? If it's Active Directory, try:
http://msdn.microsoft.com/en-us/library/ff650308.aspx
or
http://msdn.microsoft.com/en-us/library/ff647405
You could also consider: http://msdn.microsoft.com/en-us/library/ff649313
If it's not AD, you could implement your own MembershipProvider: http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
It's better to use the framework(s) where you can and only roll your own code when you have to.
We want to give users peoplesoft portal access from outside network. But ..that access needs to be read only and very limited.
Has anyone done location based role enabling is peoplesoft.. i.e. disable all roles and enable only particular role based on ip address or web server ?
I have done something similar to that using DNS entries to determine internal/external access. The users wanted to force Self-Service access to all users when they logged into PeopleSoft if they were at home, but give the users full access if they logged in via VPN or at their desk. That way, power users would not have full security unless they were authenticated via VPN or at work.
We accomplished by customizing the USERMAINT component, created a new security table for "self service" security, adding custom Signon PeopleCode, and setting up a 2nd DNS entry that was exposed for external access.
To start, the network admin set up two sets of DNS entries that pointed to the PS web servers. For example, psoft.company.com was the internal DNS and only set for local network access, and selfservice.company.com was the external DNS available for global access.
Next, we customized the USERMAINT component (User Profile). We hid the delivered Roles tab and replaced it with a copy. The new page was pointing to a copy of PSUSERROLE. We did this because we want to use the delivered PSROLEUSER table as the "current" security table. If the Security Admin wants to update a users internal (or day-job) security, we want to store if for long term. (This will make more sense below). So the new custom table, say XXROLEUSER, is now the master table for security.
Then, we added record/page/component for the Security Admin to define "self service" security (XXSSROLES). This record/page just stores Role Names for when users log in externally. This allows the Security Admin to update self service security for seasonal changes, like Open Enrollment. The admin can add a role during Open Enrollment to grant additional access, and then remove it when the period has ended.
Last, we created a custom Signon PeopleCode step that handles the internal/external security switch. The Signon PeopleCode grabs the URL used to log in. The code parses the URL to see with DNS entry was used to access the system. If the DNS entry is "selfservice.company.com", the code will clear our the rows in PSROLEUSER for the user and insert the roles from the XXSSROLES table. If the DNS entry is "psoft.company.com", the code will clear out PSROLEUSER and insert the roles form the XXROLEUSER table.
This code change turns PSROLEUSER into a transaction table. Because the Tools system relies on this table for many different security functions, it is important to create a copy to use as the "master table" for use in the User Profile component.
If this is something you are interested in trying, I'd be happy to post some sample code for the Signon PeopleCode.
I uploaded the Signon PeopleCode function to GitHub (see link below). You can create a custom record to store the PeopleCode and then add it into the Signon PeopleCode page. If you need more information, let me know. I am not able to post the entire tech spec, but I'd be happy to help if you have questions.
http://github.com/iversond/PeopleTools-Dynamic-Login
Recruiting Solutions uses a similar process - when creating the external Candidate Gateway to allow applicants to apply for positions, a 'guest' ID is created for a particular web server that has severely restricted permissions - basically just the external applicant apply objects.
In PS 9 , have a look at PeopleTools > Web Profile > Web Profile Configuration under the security tab. You can definitely secure the system at a web server level.
HTH
Disclaimer: I work for the company.
A bit late to the party, but a useful answer: IntraSee has developed a solution for this exact situation.
The key is that you need to be able to define rules (locations) and then tie those to specific roles. Evaluated at login, the roles are revoked or granted depending on the rules and user location. It can use IP or other attributes to determine roles.
To do this manually is slightly tricky as you need to account for the versioning of the user profile and associated permissions. Signon PeopleCode is the best place to evaluate these rules as you can do it once per session, and you ahve access to the business data to make correlative decisions. E.G. if a person has a huge approval limit, maybe they can't approve remotely, but someone with a small limit can. Same security access, but add or revoked based on location and data.
To your specific case: you would have base roles with read only access to those users, then a set of 'opt-in' roles that gave read/write. When they come in from the correct location, they get the read/write. So, we are only adding the extra access when appropriate.
I would create a separate site ( like the candidate gateway suggestion ), it will need a similar web profile as the one you are currently using, no other changes would be necessary.
Next create a custom menu, then attach all of the components you wish to make read-only.
Register the content references for those custom_menu.components.
Create Roles and Permission Lists adding the custom_menu.components then select "Display Only". Then assign the roles to the users.
Expose that site via the firewall.
That's it.