I am not entirely sure whether that would work. At least, there is nothing in the SAML assertion you get back from CAS that would indicate it can be proxied. There are SAML profiles that allow for delegated assertions and proxying them over, but I must admit that my understanding of those at the moment is fairly superficial. If you decided to implement this, YMMV. Most other complications are really Dashboard’s concern and shouldn’t affect your maintenance of CAS. (i.e. Dashboard needs to hold on to the access token somehow, to issue requests to the API gateway for as long as the token is valid. State management is required)
From: [email protected] [mailto:[email protected]] On Behalf Of Mitch Chang Sent: Tuesday, March 8, 2016 1:14 PM To: Misagh Moayyed <[email protected]>; CAS Community <[email protected]> Subject: Re: [cas-user] SAML support in CAS Hi Misagh, thank you for the reply. I totally agree that PT should be the logical choice for solution. The team that manages Dashboard and API Gateway is not rejecting PT as a solution. Rather, they just do not prefer having to write custom code in Dashboard to handle the PT stuff at this point and is exploring their options. They are asking us (We manage CAS servers in campus.) to find out the SAML support in CAS because they mentioned API Gateway already has an OAuth with SAML extension in place and perhaps they are more comfortable with SAML. And yes, it will likely be an OAuth access token. In addition, I believe using OAuth directly is not their first choice because of certain issues related user experience (A campus-wide CAS SSO with transparent access to API Gateway). Anyway, as you point out, Dashboard will need to support SAML to understand the SAML response from CAS. Assuming they could customize Dashboard to invoke samlValidate, and could delegate the assertion to API Gateway, would this be a legitimate solution and are there any other complications you could think of? Thanks, On 2016-03-08, at 4:09 AM, Misagh Moayyed <[email protected] <mailto:[email protected]> > wrote: < However, since API Gateway already knows how to handle SAML tokens, and the client prefers not having to write custom code in Dashboard to handle the pgtUrl for storing PGTIOU and PGTID, we are looking to see whether there is a similar solution by using the SAML support in CAS. I suppose Dashboard would obtain a SAML token from CAS when a user signs in, passes the SAML token to API Gateway, which then verifies the authenticity of the SAML token. Once the SAML token has been verified, API Gateway then returns an access token to Dashboard. Dashboard uses the access token to access API Gateway on behalf of the user. No this won’t work. If you’re not going the PT route, I’d suppose you need some sort of proxy in between. If CAS is to issue a SAML response to Dashboard, your Dashboard then needs to support SAML. They (a CAS and SAML response) can’t both be issued at the same time for one app. And, even if dashboard did support SAML you’ll need to find a way to delegate that final assertion back to the gateway, which also would be substantial work and not supported. Your other option would be to use something like ECP for the API gateway from Dashboard, but that would require you to have access to credentials and API gateway’s support for ECP I suppose. The PT route appears to be the simplest option. I am also confused; your gateway accepts a saml assertion and issues a token? How?! And, more confusingly, it issues an access token? As in OAuth Access Token? If so, why not just do OAuth in the first place?! From: [email protected] <mailto:[email protected]> [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Mitch Chang Sent: Monday, March 7, 2016 3:36 PM To: Trenton D. Adams <[email protected] <mailto:[email protected]> >; CAS Community <[email protected] <mailto:[email protected]> > Subject: Re: [cas-user] SAML support in CAS Hi Trenton, I did check out the linked document prior to posting the question. I am not convinced one can declare CAS "supports" SAML based on the linked document. I believe the document merely indicates that CAS has a /samlValidate URI that can be used to obtain a SAML 1.1 ticket validation response. We are looking for CAS to issue some sort of SAML tokens as part of the CAS sign in, and a solution similar to proxy granting tickets and proxy tickets in CAS. Thanks, Mitch On 2016-03-07, at 1:43 PM, Trenton D. Adams < <mailto:[email protected]> [email protected]> wrote: Yes, CAS supports SAML. <https://wiki.jasig.org/display/CASUM/SAML+1.1> https://wiki.jasig.org/display/CASUM/SAML+1.1 Trenton D. Adams Senior Systems Analyst/Web Software Developer Navy Penguins at your service! Athabasca University (780) 675-6195 :wq! ----- "Mitch Chang" < <mailto:[email protected]> [email protected]> wrote: > From: "Mitch Chang" < <mailto:[email protected]> [email protected]> > To: "CAS Community" < <mailto:[email protected]> [email protected]> > Sent: Monday, March 7, 2016 1:17:57 PM GMT -07:00 US/Canada Mountain > Subject: [cas-user] SAML support in CAS > > Hi, we are exploring solutions to a request in hand for CAS. We are running CAS 3.5.3. > So far we believe one potential solution is to use Proxy Granting Ticket and Proxy Ticket in CAS, but the client would like to know whether there is a potential CAS SAML solution. Here is a description of the request: > There are 2 services involved: One is a CASified service, Dashboard, and the other, API Gateway, is not CASified (and the client does not want it to be CASified). Dashboard needs to access API Gateway on behalf of the user. Naturally, using PGT and PT seems to be a decent solution and the workflow shall be similar to the following: > Dashboard obtains a service ticket when a user signs in through CAS. Dashboard obtains a PGTID upon validating the service ticket. Dashboard obtains a PT for API Gateway using the PGTID. Dashboard passes the PT to API Gateway to request an access token. API Gateway validates the PT with CAS to obtain a CAS response that contains some user information (user id for instance). API Gateway then returns an access token to Dashboard. Dashboard uses the access token to access API Gateway on behalf of the user. > However, since API Gateway already knows how to handle SAML tokens, and the client prefers not having to write custom code in Dashboard to handle the pgtUrl for storing PGTIOU and PGTID, we are looking to see whether there is a similar solution by using the SAML support in CAS. I suppose Dashboard would obtain a SAML token from CAS when a user signs in, passes the SAML token to API Gateway, which then verifies the authenticity of the SAML token. Once the SAML token has been verified, API Gateway then returns an access token to Dashboard. Dashboard uses the access token to access API Gateway on behalf of the user. > I have checked out a number of discussion threads and online documents, including <https://wiki.jasig.org/display/CASUM/SAML+1.1> https://wiki.jasig.org/display/CASUM/SAML+1.1 and <https://wiki.jasig.org/display/CASUM/SAML+Support+in+CAS+4> https://wiki.jasig.org/display/CASUM/SAML+Support+in+CAS+4 but I still cannot conclude for sure the SAML support in CAS is sufficient or not. Does anyone have any insights or have done something similar? > Thanks, Mitch > -- > 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 <mailto:[email protected]> > [email protected]. > Visit this group at > <https://groups.google.com/a/apereo.org/group/cas-user/> > https://groups.google.com/a/apereo.org/group/cas-user/. > _____ This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. _____ -- 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 <mailto:[email protected]> [email protected]. Visit this group at <https://groups.google.com/a/apereo.org/group/cas-user/> https://groups.google.com/a/apereo.org/group/cas-user/. -- 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 <mailto:[email protected]> [email protected]. Visit this group at <https://groups.google.com/a/apereo.org/group/cas-user/> https://groups.google.com/a/apereo.org/group/cas-user/. -- 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] <mailto:[email protected]> . Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. -- 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]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
