Hi, The CAS server knows the CAS protocol : it means that if your app uses a CAS client, it can "talk" with your CAS server to authenticate the user and get a set of attributes.
The OAuth server support enables CAS to "talk" OAuth on server side : it means that if your app uses an OAuth client, it can authenticate users against the CAS server (using OAuth protocol). This is the use case I had in mind when I created the CAS OAuth server support : you have two constraints : on client side, the application to protect can only use the OAuth protocol and on server side, your SSO system is a CAS server. The truth is that I also wanted to prove that OAuth protocol can be leverage on the CAS protocol. From an implementation perspective, the OAuth server support is a wrapper in front of the CAS server exposing new urls and delegating the authentication process to the CAS protocol server. Another thing you must understand is that the OAuth server support if just a subset implementation of the OAuth protocol (response_type=code is implicit, the scope parameter is not used). To answer some of your questions : - the /cas2/ url appears nowhere in the CAS server itself as it's a context path which must be configured out of the webapp, in your application server - the */callbackAuthorize is an internal CAS service used by the OAuth server support to delegate authentication to the CAS regular webflow and be callbacked in return. I'm not sure to understand quite clearly your explanations. I recommend you to read part I of this documentation : https://wiki.jasig.org/display/CASUM/OAuth+server+support. To sum up, OAuth urls (like /oauth2.0/authorize) have nothing to do with the CAS protocol, they should not receive ticket or service, but client_id, redirect_uri... Best regards, Jérôme -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
