The proxy mechanism of CAS works when both the proxied application (your API) and the client (SDK implementer) are both registered in CAS. Credentials are entered in CAS once (SSO), CAS sends the user a TGC (TGT remains on CAS server). Ticket Granting Cookie is used to verify SSO session for new services. The proxy system does indeed work like like your description in b). Client application gets a PGT (Proxy Granting Ticket) and for each request to your API will get a PT which your API will verify with CAS. There is a lot of back and forth but security is not free.
I suspect, but do not know, that the TGC is somehow tied to the browser. Unless the SDK is on the same domain as CAS, there is no way for the SDK to get the TGC. And even if it could, your API may not be able to use it. Think about it like this, if the cookie could be shared, what would be the point of log in. If you want to use a single PT for all API calls, that can be done as well. But then you have no way to know if the SSO session has expired (but maybe that does not matter). And when your API session ends, how do you let the SDK know? You could also create your own token and send that to the client as the first call to the API. But you still have all the session baggage to deal with. All this is already handled by CAS. You save yourself (and SDK developers) a shitload of work for the cost of a few milliseconds and some network traffic. If you are still interested in a token based system, look into OAUTH 2.0. It was designed for API access. If you need to add identity to the mix, OIDC is the place to be. These systems may provide a more flexibility for end users of the SDK but perhaps a little more work on your part. Ray On Thu, 2019-05-16 at 13:33 -0700, Tõnis Ostrat wrote: 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 | rb...@uvic.ca -- Ray Bon Programmer Analyst Development Services, University Systems 2507218831 | CLE 019 | rb...@uvic.ca<javascript:> -- Ray Bon Programmer Analyst Development Services, University Systems 2507218831 | CLE 019 | r...@uvic.ca -- - 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 cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/521c6a55f1497b024a89f3a30b9d045ce49296c2.camel%40uvic.ca.
