Has anyone used Crowd as the authentication mechanism for a Spring REST API? The idea would be JS clients would use Crowd to authenticate against and access a Spring REST API using Spring Security.
Community moderators have prevented the ability to post new answers.
The idea would be JS clients would use Crowd to authenticate against and access a Spring REST API using Spring Security.
If by that you mean your server uses Crowd's Spring Security integration to handle incoming requests (from javascript clients or otherwise), then yes, that should work (irrespective of whether you're using Spring's facilities to create REST APIs).
If that's not what you were asking (it does seem a pretty general interpretation of your question on my part), then please feel free to clarify :)
Yes, the idea is the JS client probably on NGINX would send an auth request to Crowd then receive a JWT or some type of token to let Spring Security know that the client has been authorized and with what roles.
Then Spring Security would hanlde the security from the Spring side of the application until Spring Security decides to expire the token.
Is that what you were thinking I meant?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not sure why you would need the javascript client / nginx interceptor here; as indicated by the link in my answer, Crowd ships with ready-to-use Spring Security integration.
(By the way, there also appears to be a third party Nginx module for Crowd, which you may want to investigate.)
If you do choose to write your own integration using Crowd's REST APIs, you should be aware that Crowd's tokens aren't strictly speaking JWTs (even though they are tokens that can be fetched in JSON form), and that Crowd has its own idea of when a token will be expired, so you'll likely be doing some wheel-reimplementing, so to speak.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe I don't fully understand the concept as a whole. My thought is the js client would need to ask Crowd for authentication. Then with this authentication go talk to Spring. Spring itself only commiunicates to Crowd to know who can talk to it at any given time. Could be an IOS app for that matter.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That approach will work too :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In a sense I would be using Crowd as an Oauth provider to verify access to a given backend application. Syncronizing users and rols amoung the backend applications with crowd. Clients being anything. Crowd being a SSO way of keeping track of everything. Techincally could use spring and roll our own. Would rather use Crowd to avoid building out something.
When you say no support for JWT. Is that something in the pipe or must use the toekns provided by Crowd?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We aren't planning any support for JWT. Somewhat surprisingly, it looks like you're the first person who might want it, because there's no issue to track adding support for it to Crowd on jira.atlassian.com. You can create an issue for it if you like (be sure to include as much detail as possible), but of course it's highly unlikely we would get around to implementing it in time for you to use it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.