user2803805
user2803805

Reputation: 127

Identityserver and SQL server Database

we are looking for brand new implementation for Identityserver4, I wnet thru the documentation and install the Project on VS2017 and DB in sqlserver.

Database is created with the default migration script provided for bot ConfigurationData as well as Operational DAta. I am very much confused , where the user will be how the clients will be add etc? Also in the startup the default ASPNEtIdentity is add, but in database there is no ApplicationUser table, so where the userdata will be? My requirement is simple - User will be aple to login to application by his credentials(or may be by 3rd party application) and will use the application or API will directly use Identity server to with clientcredential scope,

Here please do let me know:

  1. Should I introduce AspNetIdentity or Not, and Why?
  2. Where is the user table and Password of the user in the database generated by the migration.
  3. How we can add User clients and resources to the Created Database
  4. Do I need to add Login/Logout page ?
  5. In API APIResource is used to defined the Resources "api1" and same is used by the client code to get the access but this "api1" is not used anywhere with the definition/signature of the Method, so ow will it be correlated?

Upvotes: 0

Views: 4293

Answers (1)

mackie
mackie

Reputation: 5264

First off, IdentityServer4 on it's own does not handle users or authentication thereof - you either need to use ASP.Net Identity and the integration library that hooks it up to IdentityServer4 or build all of that stuff yourself.

So to sum up:

  1. Yes you'll need to use that or roll your own user store and authentication logic
  2. Either provided by ASP.Net Identity or built yourself
  3. https://www.identityserver.com/documentation/admin-ui/ may fit your needs or you could build your own tooling and/or scripts to do so
  4. Yes although the quickstart samples provide good basic starting points
  5. The bearer token middleware by default will validate the audience (ApiResource.Name) but I prefer to enforce scope at a more granular controller or action level using a filter (e.g. [ScopeAuthorize("my.api")] public MyResult ApiAction() { ... }). This filter will check that the specified scope is defined in the set of claims in the ClaimsPrincipal).

Upvotes: 2

Related Questions