I am not sure if there are easier alternatives available with the programming options, so I'd go personally for a geoprocessing (GP) service which I am most comfortable with. Suggested workflow is:
- Get the user name that is being logged in.
- The user name becomes an input for the Add Join GP tool to join the cities layer with the user name id. I guess this join can be precreated as well.
- Select only those cities features with the SQL query (where cities ID = x).
- Send the FeatureSet of the selected features to the client, so only the selected features will be drawn on the client side.
Another thing you might think of is to create individual views in the database, each of which would contain only those cities that every user could see (if you don't have very many). You would need to publish the services based on these views (or let them become created on-the-fly when the user will be logging in). Then you decide via the programming technique - what user is logged in and what map service should be added to the web application.
If you will upgrade any time to 10.1 SP1, then you could consider another solution that is ownership-based access. Basically, you can make the service return to the client only those features that the logged in user owns. This functionality was introduced in SP1. You would need then to create a field in the cities feature class and assign the user names to the "owner" column, so the service will use this field to see if a logged in user name matches the owner name and if yes, the features will be returned. Otherwise, client will just "not see" them.