I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
Stephan van Hulst wrote:
No, you really should not be doing anything security-related in your controllers. That's what the security filters are for.
Stephan van Hulst wrote:
How are the JWTs generated? Are you using one of the standard security filters, or did you insert a third-party filter into the filter chain?
Stephan van Hulst wrote:
If the filter that generates the JWT generates a token based on the SecurityContext provided by filters further down the chain, then you can solve this problem pretty easily: Just add a custom security filter at the end of the filter chain that does the following:
If the SecurityContextHolder doesn't contain a SecurityContext with an authenticated Authentication, AND the request contains user credentials, then register a new user and fill the SecurityContextHolder with a SecurityContext for the newly registered user. After the login controller action returns, control goes back up the security filter chain and the filter upstream from your custom filter will generate a token based on the Authentication object that you provided.
Please keep in mind that this suggestion is based on a very big assumption. We can provide better support if you tell us what middleware is responsible for the token generation.
Tim Holloway wrote:Some day I really ought to study Spring Security in detail, but I have been under the impression that it can (at least sometimes) build on JEE standard container security.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
None of the articles I've seen online work directly with SecurityContext. In fact, one of them claims using it to retrieve users in the controller is an outdated method
I would easily have posted the code I have already but was deterred by the fact that something as simple as user retrieval can be made convoluted enough to span multiple objects.
Tim Holloway wrote:
In the case of container-managed security, the "endpoint" (authentication and authorization) is both defined and handled solely by the container. The only choice the app itself has is to specify which type of authentication front-end (dialog or form) will be used, and technically, the web.xml file is considered a (server-independent) deployment descriptor rather than strictly application code.
The actual security mechanisms in container security are defined via plug-replaceable components configured into the webapp server (using the other (server-dependent) deployment descriptor. Thus I can use an XML file for testing and LDAP and/or a database for production without rebuilding the webapp.
Tim Holloway wrote:
Aside from this complete isolation between security application and administration (i., e., creating/updating accounts, there's another good reason for keeping account maintenance out of the application. When you're using, for example, a database as your A&A reference and allowing it to be updated within your webapp, that means that the entire webapp has potential access to a database connection pool with greatest-common-denominator access to both business and security data from any user. Instead, I highly recommend using a separate webapp (or other channel) to maintain the A&A data.
Indeed, it's common in large enterprises for the security profiles to be created and maintained solely by a security management group and there would be no purpose in letting them into your business logic any more than there would be to allow a user to be able to potentially enable themselves to unrelated apps in a shared security environment.
Note that I do draw the distinction between security profiles and user profiles (preferences). User profiles tend to be per-application, and shouldn't have anything in them that allows privilege escalations.
There is of course, a difference between internal security and external application users. If I'm setting up the next Amazon.com, I do want new users to be able to register accounts and maintain (within limits) their security options. And there are industry best practices for that kind of stuff, but it's not specific to Spring Security.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |