You feel very good. Although the user interface layer interacts with the client and takes its password, your service level should handle system input attempts.
Your action methods pass information to the service entities responsible for authorization.
The service layer has no idea whether it is in the web application or not.
Data levels are where this information is stored, not where it is processed.
You might want to save the user ID in the user interface layer in the session. Upon entering the system, the service level will accept the username / password / whatever and return the UserID. Or, your action methods may each time pass the session key to the service level to get information about the user.
Edit due to comment: I am doing this in my current project (a couple of million dollars). I have security methods in action methods. (Although, of course, the tools for this simple are objects from the service level.) For example, if the current user does not have this role or role, redirect them to the reject page, otherwise do it. MyServiceLayerObject.DoThing() has no security inside.
This is the easiest way for my application and many others. (“Simple” means that it will be the least scrupulous. When it comes to security, everything is just fine!) Since the Action method is a gateway to functionality, having security at the service level will simply lead to additional work and it is virtually unclear what kind of security was happening. Now this is my application, where there is usually a place where every action takes place.
Your application may be different. The more different action methods and (especially) different components use the functionality of your service level, the more you want the functionality of your service level to be blocked by your authorization scheme. Many believe that security should always be at the service level and that any additional security actions at the user interface level will be bonus redundancy. I do not agree with that.