Ok, there are three things you can do in increasing order of preference.
1) Use "is" to explicitly check the class of the object. The problem with this approach is that it's brittle. If you come up with new subclasses in the future you need to change your condition. This breaks the "open/closed principle": you shouldn't need to modify code that exists in order to add new features.
2) Implement a "hasDetails" method in Person and override it in User. You then check "hasDetails" which you can then implement in any class that implements that interface. This is preferable because it allows you to add new code without changing existing code but is inflexible because it assumes that all details are the same.
3) "Tell, don't ask". Don't ask the object for information about itself and do something based on the result. Instead, tell the object to do the operation itself. This allows the object to decide when to do it and how to do it.
Using #3 is preferable in most cases but there are situations where you really have no choice but to go with #2 (eg. packaging or layering requires that the operation you want to perform can't be done by the Person object) or even with #1 (eg. you don't have access to the source code of the Person class or can't add methods to it).