User identification

[nikmd23]

Provide a mechanism for users to enhance the Glimpse experience by annotating user sessions with some sort of meaningful identifier. (Name? Username? Email?)

@leastprivilege has a nice write up about security in ASP.NET 5. His article leads me to believe that we might be able to leverage claims.

If this system worked automatically with other popular authentication frameworks, than that's even better.

We might want to consult with @leastprivilege & @brockallen about this, cause I'd love to make sure "it just works" with @IdentityServer

[brockallen]

IdentityServer uses the sub claim (as defined in the OpenID Connect specification) to uniquely identity the user.

[nikmd23]

Are picture and/or email set then as well? Or at least easy for the developer to have set?

[nikmd23]

High Level

User identification will publish a message like this:

{
  id: "(standard message Id)",
  type: "user-identification",
  payload: {
    userId: "(a user id)",
    username: "(a display name for the user)",
    email: "(the email address for the user)",
    image: "(fully qualified path to user image)"
  },
  context: { id: "(standard request Id)", type: "request" },
  indices: { request-userId: "(same as payload.userId)"  }
}

Detailed Breakdown

• The id, context.id and context.type values have standard meaning across all messages.
• type: This is a predefined string. I'm proposing user-identification, but that can be changed if a better name is provided.
• indices.request-userId: A predefined key used to promote the payload.userId value into the indices collection for searching purposes.

• payload: The payload has four properties:

  1. userId: The unique identifier for the user within the developers application.

     This will default to the sub claim, as defined in the OpenID Connect Standard Claims. If sub is null or white space, than fall back to NameIdentifier. If that is null or whitespace, another framework specific identifier (like session ID) should be used.

  2. username: The display name for the user within the developers application. May be a "handle" or real name.

     This will default to the name standard claim. If name is null or white space, a CRC-16 hash of the userId should be used.

  3. email: The email address for the user within the developers application. This value is optional.

     This will default to the email standard claim. If email is null or white space, email may be omitted.

  4. image: The fully qualified path to the avatar for the user within the developers application.

     This will default to the picture standard claim. If picture is null or white space, a Gravatar URL based on email should be generated. If email is null, a Gravatar URL based on userId, with the ?d=identicon parameter added, should be generated.

Example

Authenticated

For a logged in user, the published payload could be as simple as this:

{
  userId: "nikmd23",
  username: "Nik",
  email: "nik@example.com",
  image: "http://www.gravatar.com/avatar/e07a27ec61977c7c686feaa799b1cf6e.jpg"
}

Which might output something like:

Nik

Guest

For a user who is not logged in, this is what might be published:

{
  userId: "5b863580-202b-4c6a-8fec-dd8cfe07db22",
  username: "E746",
  image: "http://www.gravatar.com/avatar/5435e45ccc985662024892ee58472c31.jpg?d=identicon"
}

Which might output something like:

E746

Still To Be Implemented

For this to work, the following (and more) may needs to be implemented:

• [ ] An IMiddlewareProfilerComposer that runs after the call to next() when authentication has already happened.
• [ ] Updates to IQueryRequests to support request-userid
• [ ] Client work to render the client

[brockallen]

One additional comment I should make: if there is no sub claim, then you might want to look for the NameIdentifier claim (https://msdn.microsoft.com/en-us/library/microsoft.identitymodel.claims.claimtypes.nameidentifier.aspx). This might be present in lieu of sub for some types of applications.

[nikmd23]

Thanks for the info @brockallen!