I am new to Identity server but I found it quite easy to set up.
Our goal is to implement SSO down the line but at the moment we are just moving our authentication logic out of application.
It is going good except I have one confusion.
When I set up the Idsrv, I had to create admin user as well as token requesting user. This was to access and configure Idsrv.
For application auth, I have to use Idsrv as federation server as well and authenticate users against some Asp.Net data store.
Now there is already one data store where Identity server specific users are stored.
Should I be using same store for my application user auth and created/edit these users in that store? Or can I/should I create a separate database for application specific users and use both?
At the minute, I am authenticating application users against Idsrv store.
I am not sure if I am logically thinking in right way to split these two user sets and calling one as Idsrv specific users. (We will have Identity service separately deployed for each application)
Thanks for your help in advance.
Related
I have a legacy, monster software that is built around SQL membership. It isn't the most elegant code and sometimes the code goes directly into the database to pull users or roles out.
I need to migrate this to Active Directory. I'm thinking of authenticating against Active Directory, then saving the user on-demand into SQL. That way, the rest of the code works when trying to work with users, roles, etc against SQL. I would also have to plug the places where users are created and deleted.
Is it possible to authenticate against Active Directory via form authentication, but use SQL membership for the rest?
I'm sure what you ask is possible, but you may want to consider authenticating against ADFS instead of directly against Active Directory.
ADFS issues security tokens you can use to make authorization decisions. You can have it issue role claims into the token based on look-ups in a SQL attribute store. If your application is using things like IPrincipal.IsInRole to determine permissions, it should not have to change much.
Moving your application to token based authentication will make it easier to make your application internet ready (ADFS proxy) or trust issuers from other authentication domains (federation).
I have a .NET Web API with a bunch of end points/methods that an Angular App calls. I want to now implement the login system against our active directory, and wondering what my options are.
Back in the days, it was simple: windows or forms authentication, and then just some simple configuration in the web.config, and may be a custom provider. But now it seems like there are a lot more options with OWIN, OAuth, token based authentication, etc.
Where do I start? I have a form with username, password, and a login button on the Angular app, and I have the active directory in the backend. What should happen after the user hits the login button? Any direction would help.
Thanks.
Well, it depends on what you actually need.
If you want to authenticate only AD users then you can try authenticate in AD on their behalf and in case of success you return either token or authentication cookie.
But I don't think it is a good idea to make users use their domain password unless you have two factor authentication.
It's better to extend AD schema with additional data for authentication through your service or even to have standalone auth server with associated domain user info. Look how it is done in SQL server (but in reverse direction): you need to define internal user corresponding to domain login. This approach allows you to have users that do not belong to AD, sometimes this can be important for outsourcing some tasks.
Look at IdentityServer
I am creating a project which has a login portal with multiple applications and websites. I want to allow the user to login and then click any application and have access to it. Some considerations are: each application is defined in a user profile, ie which users can see what. also each application privileges are different for each user. so user a may be an administrator of application a but just a normal users in application b.
What i know.
I can have one auth cookie created in the main portal which with setting the machine key and same authcookie name, each application can use it. I have done a test with this and it seems to work.
My problem
As each site/ virtual directory has different privileges per user and per application when the user access a site i need to get his privileges from the databases but I cant then overwrite the auth cookie userdata with the new details because he may have multiple tabs etc open at a time on different sites. So how can i have an extra cookie store per user and per application for holding application specific details. I know I could go to the database each time but that's allot of overhead for each post back.
Maybe another option is to use the main authcooke for checking the user is logged in then have a new auth cookie per aplication and user, but how can i have 2 authcookies, that may get confusing and the second needs to timeout when the main one does et c i think
Any help suggestions would be gratefully appreciated
THanks
------------------- EDIT -----------------------------
we have one user table for all all sites not 1 per each site. then we map the user to an application and then the user application and role. so when you get to an application it has to check if the user has access and what there role is. all other user details are already in the auth cookie when loggedinto the main site. We do it this way because we have to manage users in one application not each application. Hope this helps understand my requirements.
What you are describing is a 'classic' SSO (single sign-on) example. There are lots of ways people have tried this and they are well documented on Google.
One way to do this is to have your SSO server (e.g. the first place you land and log in) to issue a security 'token' (e.g. a Guid) and then either store this in a cookie or append to URLs. Each subsequent call to an application can look-up the token in a database, verify it's validity and carry on (or boot the user out if invalid).
Using a database also allows you to set a timeout for all applications for which the token is valid.
This can then be extended to allow the database to store which apps each user can access etc. I've described this in very broad terms but it may be a good starting point.
Hope this helps
BTW: querying the database on each request isn't too much of an overhead. I have applications that do just that and are still performant when loaded with 300+ users.
I'm working on a single sign-on solution for two ASP.NET MVC3 websites. The sites are on separate subdomains. I'm using Forms Authentication and so far I everything is working well. When I sign into a.example.com I'm automatically signed in to b.example.com too. Nice.
Each application has its own database.
My question is this - if I want to keep certain user information in sync between the two sites (say the last activity date or some user preference) then should I have a User table in both databases and somehow keep them in sync or should only a.example.com's database have a User table and b.example.com somehow reads and writes to it?
Thanks for your advice.
Edit: Thanks to adam I'm leaning towards storing all user data in a separate database. I will pass the authenticated user's username and ID to each application in the authentication cookie. Can anybody offer any advice around maintaining referential integrity between the two databases?
Most SSO solutions I've seen have a central accounts portal where users can maintain settings, change email address etc.
Think Google:
google.com/reader
google.com/analytics
google.com/accounts
This represents a single user store, providing authentication to several sites. This has various benefits, such as a single place to store session hashes and other security details (for preventing things like man-in-the-middle attacks).
In a true SSO, an authentication request redirects to the central auth system (ie google.com/accounts), authenticates and then redirects to the service that requested authentication.
From your description, it sounds like you have separate authentication for each site/service, but the user db is shared.
I am building a suite of applications using ASP.NET.
Each application can be hosted on separate servers.
All the applications share an integrated database.
All applications require user authentication before use.
I want to build the ability to transfer users from one application to another without having to relogin.
Is there a way to recognize that a user is logged in one application and allow quick navigation to another application on a different server?
Currently I am storing the password hashes in the database; but I wouldn't be opposed to other suggestions if they solve the problem.
Here is what I have done in the past.
Each application must share a forms authentication ticket. To do this the forms authentication cookie name must have the same name, the machineKeys must be the same, and the protection mode must be the same.
This works across domains, but does not work across IPs. What I do to get around this is to serialize the ticket info and store it in the database with the session id as the key. If a user is not authenticated the server will look for the session id in the database and rebuild the FA ticket if found.