1

I have a rather different use case where I have to track the login history, and to track them I'm creating a new GUID in the IProfileService and adding it in the claims and also to the DB , to continue front end task.

The issue is I get multiple DB entry for a single login click, which starts displaying two records per login.

The GUID is used to track the current login session.(We have concurrent login scenario)

Question 1 - Is the GUID creation within this function the right thing, if not where to do it?

Question 2 - Does IDSvr provide a Unique Id for each login, so that i can just use it in the claims.

Question 3- How I stop/minimize the other DB calls made because of multiple calls.

public async Task GetProfileDataAsync(ProfileDataRequestContext context)
       {
           var user = DataBaseUserRetrive();
           var claims = new List<Claim>
           {
                        //All Claims from user
           };
               string deviceIdGuid = Guid.NewGuid().ToString();
               Claim deviceId = new Claim("device_id", deviceIdGuid ,ClaimValueTypes.String);
               claims.Add(deviceId);
               await databaseCall(user,deviceIdGuid );
          context.IssuedClaims = claims;
       }

PS :- I'm quite new to Identity Server

Babloo Singh
  • 11
  • 3
  • Read my answer [here](https://stackoverflow.com/questions/48006060/identityserver4-too-many-calls-cause-performance-issue/48007146#48007146) for an explanation why it is called multiple times. –  Nov 26 '19 at 11:02
  • As for logging, why don't you log the succesful login in the Account.Login method? As you've already encountered, the ProfileService isn't a reliable place to log since it can be called by other processes as well. –  Nov 26 '19 at 11:05
  • @Ruard I also have to add this newly created GUID in the claims, and I couldn't find a place to add it into the claims other than this method. The multiple call, I understood the different context, but my application only requests for token and doesn't get called by a user end info. Again my question still remains the same, can I add this custom claim anywhere other than this method, if yes then where and how can I integrate it. – Babloo Singh Nov 26 '19 at 18:26
  • You can add the claim in the ProfileService while logging the succesful login in Account.Login. –  Nov 26 '19 at 18:30
  • ProfileService is called after my successful login if I'm not wrong? And I'm assuming it gets called internally, because we register it in the services. How can I create a GUID in account controller and ass is into the profile service, getprofiledata only gets a context. PS - There isn't anyway for me to retieve this GUID after storing, like this is kind of unique primary key. – Babloo Singh Nov 26 '19 at 18:36
  • Identityserver4 allocates a unique session ID each time a user signs in. This is stored as a property inside the authentication cookie called session_id. It would make sense to use this to track sessions. If you just want to track each time a session ID Is allocated then you could provide your own implementation of IUserSession that does the necessary logging. – mackie Nov 28 '19 at 20:32
  • @mackie Thanks I'll try this, can you give a IUserSession Implementation example? I couldn't find an example relating to this in the official docs. For now i have implemented IClaimsTransformer to add a GUID within the principalClaim and logging, and in ProfileService I'm just accessing it to add it in the claim – Babloo Singh Nov 29 '19 at 08:50

1 Answers1

0

To expand on my comment on the OP - I think a custom implementation of IUserSession (or inheriting and overriding virtual methods in DefaultUserSession) is probably the correct place to intercept session related events and add custom behaviour and logic.

The default implementation is here: https://github.com/IdentityServer/IdentityServer4/blob/3.0.2/src/IdentityServer4/src/Services/Default/DefaultUserSession.cs

Check out the method EnsureSessionIdCookieAsync() - that's probably a good place to wire in any custom logic.

This session ID is what's sent to clients and forms part of the protocol - in particular the front channel logout and session monitoring specs.

mackie
  • 4,996
  • 1
  • 17
  • 17