Representing logged in users

How do microservices know who’s logged in? makes the assumption that microservices can work together automatically if they use the same semantic model.  Microservices know who is logged in by following the correct semantic model.  The semantic model to follow is explained here.

The difference in life-span of a session and a user account is very different.  The session is ephermal, if a user agent doesn’t show up for too long we may want to clean its session information.  The user’s account is longer lasting.  If you revisit our app five years from now, we want to remember your profile.

Account information

The FOAF ontology makes a difference between a User and a User Account.  This split allows you to have many accounts through which you can log in.

The user information is commonly represented by an instance of class foaf:Person.  This subclass of foaf:Agent represents people with their naming info.  If you need access to display the name of the person, find it in foaf:name.  This contains the preferred name for the user, be it a full name, given name, or nickname.  Unless the application domain requires it, this name may not be unique.

The account information is represented by an object of class foaf:OnlineAccount.  We attach the username to the account by connection of foaf:accountName.  An example would be the twitter handle, the email address, or the nickname by which you can login into the account.  If your users can login both through twitter and through username/password then a user can have two instances of foaf:OnlineAccount linked to their foaf:Person.  Find the accounts for a user by following the foaf:account predicate from the foaf:Person.

The distinction between foaf:OnlineAccount and foaf:Person is important when adding information to the user.  Most information will be attached to the foaf:Person.  Information may be specific to a single account, or attached to the user in general.  Each account through which the user may login may have its own icon attached to it.  The provider of the account stores the icon and we may want to display it.  This icon would be attached to the foaf:OnlineAccount.  If the user has an icon to be shown when the application refers to the user, then this icon should be attached to the foaf:Person.  The same goes for interests, age group, past orders, etc.

Session information

The session URI for each user is generated by the mu-identifier.  It is available in the MU_SESSION_ID header.  The session URI points to the foaf:OnlineAccount after the user logged in by use of the predicate musession:account.

You may want to attach much more information to the session than just the account as explained here.  You could let users play with your application before they create an account.  Getting them hooked before they have to invest.  You may want to let them fill in their shopping cart, and only let them login or register when they’re ready to place their order.  A reactive microservice can move the information around as necessary.

Overview of used ontologies

A few ontologies, types, and predicates have been mentioned here.  We list them in this overview for easy reference.

Used prefixes

Prefix URL

Used types & predicates

Prefixed name Description
foaf:Person Type representing a user on your site.
foaf:OnlineAccount Type representing an account through which a user can login to your site.
foaf:name Predicate attaching a ‘name’ to a foaf:Person. Can be anything ranging from handle, nickname to official name.
foaf:accountName Predicate attaching a ‘name’ to a foaf:Account. Use this when showing multiple accounts of a specific user.
foaf:account Predicate connecting the Person to his OnlineAccount. From Person to OnlineAccount.
musession:account Predicate connecting the current session to the OnlineAccount by which the user logged in. From session URI to OnlineAccount.

Used HTTP headers

header Description
MU_SESSION_ID HTTP header containing the URI of the current user’s session. Might not be used in the database yet.

Documentation of foaf can be found at


The model uses for representing users has three levels: the session, the account, and the user.  Information can be attached to either of these three, microservices using this model automatically interact with the logged in user.