Cartman tries to name things #175321

[cartman82]

I am working on extending the security system a bit for my web api.

The way it works now:

• Client's request has a token in the header
• We use the token to resolve User record from DB (so no JWT )
• This record is then used by the target service to resolve whether this request is authorized to do what it's trying to do.

This is done primarily using user.id and user.role, which are parts of the User model.

I now want to extend this record to also include company.id, which is obviously not part of the User (since user can have access over multiple companies). In the future, I might also cache a few other things there too.

So how do I call this entity that is now to be passed instead of User?
We are looking at something like this:

{
  user_id,
  company_id,
  display_name,
  access_token,
  created_at
  //... more stuff later?
}

Some candidates that came to mind:

• Identity (my no 1 choice ATM)
• Ticket
• SecurityContext (context)
• UserWithSecurity (uws)

Is there something better? Perhaps some industry-standard name for this thing I am not aware of?

[Maciejasjmj]

@cartman82 add Principal to your thesaurus.

Honestly though your user is still a user, just with some more data.

[anotherusername]

That sounds like a Session.

[gwowen]

@cartman82
Session if its something that's intrinsically time-limited.
Identity if its permanent-until-cleared.

[anotherusername]

@gwowen I would generalize that a bit further: Session if it's intrinsically dynamic, Identity if it's intrinsically static.

Other types of limitations would also make it a session. E.g. if it's limited to that computer/browser. Or, since he said this:

@cartman82 said in Cartman tries to name things #175321:

user can have access over multiple companies

...that suggests to me that it might be limited to that company, and that multiple structures could be created if the user logged in over multiple companies.

If logging out/logging in/using a different browser/computer will cause a different structure to be created, it's a session.

[blakeyrat]

@cartman82 Credential

[anotherusername]

#175321 is a stupid name, BTW. You definitely shouldn't name things that.

[cartman82]

@maciejasjmj said in Cartman tries to name things #175321:

@cartman82 add Principal to your thesaurus.

Ah, I forgot about those. It actually matches pretty closely to what I am trying to do. On the downside, it seems very MS/Windows specific.

@gwowen said in Cartman tries to name things #175321:

@cartman82
Session if its something that's intrinsically time-limited.
Identity if its permanent-until-cleared.

This is tied to an access token, so I guess it kind of matches the concept of session (although we don't have automatic expiry ATM).

I avoided that term because "session" is used in a few other places for different things.

@anotherusername said in Cartman tries to name things #175321:

...that suggests to me that it might be limited to that company, and that multiple structures could be created if the user logged in over multiple companies.
If logging out/logging in/using a different browser/computer will cause a different structure to be created, it's a session.

Exactly. You can open the app on your PC and log in as company 1, then open it on your phone and enter as company 2. It's tied to the token that's in your cookie / local storage.

I guess it is session, huh.

@blakeyrat said in Cartman tries to name things #175321:

@cartman82 Credential

I always considered "Credential" to mean username/password combo or a security token, stuff like that. Something you send to prove who you are.

[dkf]

@cartman82 said in Cartman tries to name things #175321:

On the downside, it seems very MS/Windows specific.

What? No! The concept most definitely is portable. A principal is someone or something that proves who it is in order to access a service or resource. A credential is something they use to do that. Often they do the access by establishing a session with the service so that they can communicate multiple times with the service without reauthenticating, but that's logically optional.

“User” and “Principal” are pretty similar; the difference is that user-ness is from the service's perspective, whereas principal-ness is from the client's perspective.

[boomzilla]

@cartman82 said in Cartman tries to name things #175321:

I now want to extend this record to also include company.id,

My first thought is something like CompanyUser. Because it's a user, but associated to a company. Reality is probably more complicated.

[anotherusername]

It's not a half bad looking color though.

[ben_lubar]

@anotherusername said in Cartman tries to name things #175321:

It's not a half bad looking color though.

[Luhmann]

@ben_lubar
Is it me or are your images getting smaller?

[Zecc]

@ben_lubar I'm a bit disappointed you didn't sneak a pixel of a different color in there.

[cartman82]

@zecc said in Cartman tries to name things #175321:

@ben_lubar I'm a bit disappointed you didn't sneak a pixel of a different color in there.

How could he, it wasn't in the title.

[cartman82]

@dkf said in Cartman tries to name things #175321:

What? No! The concept most definitely is portable. A principal is someone or something that proves who it is in order to access a service or resource. A credential is something they use to do that. Often they do the access by establishing a session with the service so that they can communicate multiple times with the service without reauthenticating, but that's logically optional.
“User” and “Principal” are pretty similar; the difference is that user-ness is from the service's perspective, whereas principal-ness is from the client's perspective.

Here's a SO answer with more details.

What is the meaning and difference between subject, user and principal?

In the context of security frameworks, a few terms commonly occur subject, user and principal, of which I have not been able to find a clear definition and the difference between them. So, what e...

They even did a chart to make it "clearer".

Bottom line, it seems I can use either Principal or Session for what I have. Session probably fits a bit better, but Principal is a more unique name in my system.

So I think I'll try to go with that.

Thanks everyone.

[cartman82]

BTW, does anyone have any opinion on JWT-s vs standard stateless tokens?

When I first learned about JWT-s, I immediately had a negative gut reaction. I don't trust all these clever cryptography tricks, that tend to suddenly turn out not so clever after all, and then you have to scramble to fix things. Give me nice and simple random tokens, which I fully understand and control.

This guy seems to agree:

Rahul Golwalkar  /  Aug 21, 2016

Pros and cons in using JWT (JSON Web Tokens)

For apps that require a sever-side implementation, the clients (mobile app or web browser)generally have to prove their identity to the…

Any thoughts?

[dkf]

@cartman82 said in Cartman tries to name things #175321:

Any thoughts?

That's an awful one-box!

[Maciejasjmj]

@cartman82 said in Cartman tries to name things #175321:

Give me nice and simple random tokens, which I fully understand and control.

If you can do that then you don't need JWT. It's primarily for SSO applications where you not only need to verify the user is who they claim to be, but also that they got the token from a legitimate source. If that source is you, then you don't need to check if the token is legitimate since you can just look if that's the token you've sent out.

[cartman82]

@maciejasjmj The way to do that without JWT would be to reach out to the issuer (API request) and resolve token with them. With some caching, this might be just as fast as going to the database.

I suspect you'd need to have a really big system before JWT-s start paying off.