-
Notifications
You must be signed in to change notification settings - Fork 187
Any plans for OpenID/OAuth support? #32
Comments
What do you mean exactly? Should CASino act as OpenID/OAuth server or should it support authentication using a OpenID/OAuth source? |
Authentication using an OpenID/OAuth source. Great project by the way. :) Take a look at this: |
Just out of curiosity, what would be the use case for this? Why wouldn't you directly add support for OpenID or OAuth to the client applications? |
I'm also investigating this gem and it looks to me like the missing feature. If I were to implement oauth client to any app it's not only dup code but would also lose SSO, right? |
However, now I wonder if it would be the correct way to
Is it somehow compatible? |
Ok, understand the use case for this now. @kassi I'm not quite sure I understand the setup you are planning to do.
There is ominauth-cas which is compatible with CASino.
Devise defaults to BCrypt for the password encryption and should therefore be compatible with our ActiveRecord authenticator.
As CASino does not feature user management out of the box, it is pretty standard to handle sign-up in an external application.
No, as you can only specify one
Just found device_cas_authenticable which should be compatible. |
Thanks for the reply. I think there's still a misunderstanding since omniauth-cas as well as devise_cas_authenticable seem to be gems you add to some app which will use another app (cas server) for auth. My aim is to have one app designed to manage users, sign up and sign in (also via external oauth services), and have several other apps only use this one app as central single sign on point without having to implement several services and user model again and again. |
CASino is a Rails engine and can therefore by used in any existing Rails app providing sign-up etc. I know that @dlindahl built something similar. To add support for login through OAuth, writing a CASino authenticator would be the right approach. CASino uses it's own technics to track logged in users and is not compatible with how omniauth or devise does this. |
I'm interested in this support as well, to allow users to choose whether to use Google, Facebook, Twitter, or GitHub accounts, or create a local account. |
@pencil how would one go about writing a strategy supporting Oauth? The API for CASinos authentication is a username and password getting POSTed to the login route. Then the strategy eventually validates the username and password. In the case of OAuth we arrive back from the OAuth provider via a GET request and have various tokens to keep track of. But not exactly a username or password. Not sure how that fits into the current CASinoApp flow. Is it possible to fit this to the current implementation of the engine or would additional functionality / rewriting be required? |
No, it does not fit into the current CASino workflow. The best way would probably be to start off with an "external authenticator" abstraction. Then display a button for all external authenticators at the login page. As this issue is currently not in our focus, I'll close it for now. I'd gladly look into a pull request though. Feel free to contribute 😉 |
I've noticed that Jasig CAS has support for third-party protocols, any plans to bring that to CASino in the near future?
The text was updated successfully, but these errors were encountered: