Let's walk through this step-by-step, maybe I can explain myself better or see the error of my ways. Either I'm just stupid (which is a real possibility :/ ) or we're talking about two different things.
Let's say that I have a working service accessible on "https://api.mydomain.com" and now I want to ship a SDK to my users. Are you telling me the SDK is supposed to both know how to interact with my service *and* the CAS server? If so then what exactly happens when the user wants to make 4 requests to get information from my service? Should the SDK a) send the user's credentials to CAS every time, receive a new TGT, request a ST for my service with that TGT and then pass that to my service? or b) send the user's credentials once on instantiation, store the TGT and before the requests use that TGT to request a ST and then pass that to my service? If it's the former then it's just a shitload of useless back-and-forth between CAS and the SDK If it's the latter then what's the difference between a) requesting a ST from CAS, sending it to me and having me validate it in CAS vs b) sending me the TGT itself and having me validate that in CAS On Thursday, May 16, 2019 at 10:27:05 PM UTC+3, rbon wrote: > > That is the purpose of tools like CAS. Let it manage user authentication. > Some application (client in OAUTH) will interact with your API. There is > CAS proxy protocol for this. Client app interacts with CAS for log in; when > it wants to call your API, it gets a proxy ticket and sends it to your API; > your API validates the ticket and does what it does. > > You can also checkout OIDC and OAUTH for an alternative approach using > tokens. > > Your idea is sound. But you do not need to reinvent access methods. > > Ray > > On Thu, 2019-05-16 at 10:31 -0700, Tõnis Ostrat wrote: > > I strongly discourage you from asking a user for credentials > > > How do you propose then that I have my users authenticate themselves to be > able to use my API if it's a completely standalone back-end service with no > GUI? > > On Thursday, May 16, 2019 at 6:20:09 PM UTC+3, rbon wrote: > > Tõnis, > > I strongly discourage you from asking a user for credentials; security, > break SSO, etc., etc,. > > There is a proxy option in CAS, > https://apereo.github.io/cas/6.0.x/installation/Configuring-Proxy-Authentication.html > > If the proxy option does not meet your needs the surely something else > under https://apereo.github.io/cas/6.0.x/index.html Authentication | > Methods (JWT or PAC4J might be good). You could also try OIDC, > https://apereo.github.io/cas/6.0.x/protocol/OIDC-Protocol.html#openid-connect-protocol > > Ray > > On Thu, 2019-05-16 at 03:32 -0700, Tõnis Ostrat wrote: > > Hey, everybody. > > To preface this, I've tried both googling and looking through the > discussions here but still haven't found an answer for the following > situation. > > I'm currently building a back-end service with no web-based nor native GUI > and I'm having trouble coming up with a proper way to secure it with CAS > (5.3, if that matters). > > My plan right now is to have an endpoint in my API where the user can POST > their credentials which I will forward to CAS's REST API (with the ID of my > service) .I will then return the TGT that CAS gives me to the user and on > any subsequent data request I will try to extract the same TGT (header, > cookie, whatever) and validate it by requesting a ST for my own service > from CAS. It *works *but it sounds a bit stupid because I don't actually > do anything with ST, it's just a confirmation call to make sure the TGT is > valid. > > This flow is the one I've managed to piece together basically on my own as > the REST API portion of the official documentation is really lacking in my > opinion. > > Is there a better solution to this problem? > > -- > > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 | CLE 019 | [email protected] > > -- > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 | CLE 019 | [email protected] <javascript:> > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/b263d1f8-85db-4217-86f6-42635a4844b3%40apereo.org.
