Message authentication (sometimes called data origin authentication) is the assurance that a given entity was the original source of the received data.
Entity authentication (or user authentication) is the assurance that a given entity is involved and currently active in a communication session.
A MAC provides data origin authentication as the receiver knows that the message and corresponding MAC could have only come from the one person with the shared key. Used on its own, a MAC will not give you entity authentication.
A digital signature also provides data origin authentication as the verifier knows that only the owner of the private key could have produced a valid signature. Used on its own, a digital signature will not give you entity authentication.
You mention a shared symmetric key and whether or not a security service is provided. You are likely confused with non-repudiation. Non-repudiation is the assurance that an entity cannot deny a previous commitment or action. If there is a shared key (such as in the MAC setting) one user could deny having produced a MAC tag on the message as the key is shared- external parties are not sure which owner of the MAC key could have produced the tag. Whereas with digital signatures, each key is unique to each user, so there is non-repudiation as only one user could produce a valid signature.
Used naively, neither MACs nor signature provide entity authentication as signatures/MAC tags could be forwarded or replayed. Recall: message authentication provides assurance on the original source and does not tell us anything about when the message was sent or who is sending it now.
Consider the following scenario with data origin authentication but no entity authentication: Alice could sign a message and send the message and signature to Bob. Bob could then forward the message and signature to Charlie, who can verify that the original source of the signature was Alice (as there is message authentication) but not that they are communicating with Alice now. Hence there is no entity authentication.
To get entity authentication, we need some kind of freshness. For example, for Charlie to be assured about Bob's identity and current activity, Charlie could request Bob produce a valid signature on a fresh nonce, generated by Charlie. This ensures that Bob is currently active and that the signature came from him. Obviously, this may be vulnerable to man in the middle attacks (Bob could forward the none to Alice to sign, and return the signature to Charlie), but there are things that can be done about this (for example, by asking Bob to sign the challenge along with a session ID: the session ID is unlikely to be the same as the session between Bob and Alice, so Alice would not sign).
In general, think of entity authentication as data origin authentication + freshness.
Reference: Everyday Cryptography, 2nd Edition by Keith Martin (2018).
