[cas-user] OIDC - using ID token as Access Token

[Ivan Obradović]

Hi guys,

Currently I'm using CAS and OAuth 2.0 protocol and would like to switch to 
OIDC. As I saw OIDC implementation is built on top of OAuth implementation. 
It is using the same mechanism to generate Access and Refresh token, and 
adds new ID token to response.

Is it possible to use ID token as Access token or will it be possible in a 
future version of CAS server ?

I have several Rest API resource servers and all of them has to send 
requests to CAS server to validate Access Token. If I switch to OIDC I 
expected Access Token is the same as ID token so my Rest APIs can validate 
JWT token without sending request to CAS server. However Access Token still 
is meaningless text, and all have to be done the same like for OAuth 2.0 
protocol.

Am I wrong ? Could this be done in OIDC/ID token way or not ?

Best regards,
Ivan

-- 
- 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/25f262a4-b90c-4b5f-96ee-113b3299d247%40apereo.org.

[cas-user] CAS 5.2.3 + OAuth2.0 issues

[Ivan Obradović]

Hi,

I'm using CAS server as SSO solution in my company. I'm upgrading it from 
v4.1.7 to v5.2.3 and have some issues with OAuth2.0 implementation.

1. SSOut does not work for web application which are authenticated via CAS 
server using OAuth2.0 Authorization Code Grant flow.

The problem is that on CASified application side, class 
org.jasig.cas.client.session.SingleSignOutHandler.recordSession retrieves 
Authorization Code and stores connection between session and Authorization 
Code (sessionMappingStorage.addSessionById(token, session))
On CAS server side when SSOut request is sent to all authenticated 
applications it sends service ticket in SSOut request (Bask chanell SSOut 
request is used) not Authorization Code. 
org.jasig.cas.client.session.SingleSignOutFilter on CASified application 
detects SSOut request, extracts token (service ticket) from the request and 
tries to find session, which should be invalidated, which are related to 
the token. But there is no such session because all sessions are related to 
OAuth2 Authorization Code.

Possible soolution would be:
On CAS Server side, on OAuth2.0 Authorization Code Grant authentication, 
generated Authorization Code should be stored in 
TicketGrantingTicketImpl.services, the same way as it is done for service 
tickets.
In this way, CAS LogoutManager will pull authorization codes and service 
tickets for TGT and sends SSOut request for all of them.

2. Exception handling of OAuth2.0 requests

If incomplete/invalid OAuth2.0 request is sent e.g. without grant_type 
parameter of wrong value for grant_type

https://host/cas/oauth2.0/accessToken?client_id=client1=u...@gmail.com=x
https://host/cas/oauth2.0/accessToken?grant_type=invalid_id=client1=u...@gmail.com=x

the response is: 
Status: 400 Bad Request
Body: error=invalid_request

There is no information what is wrong. In old version v4.1.7 the response 
contained information what is wrong. For instance, Google and Facebook also 
give information what is wrong with the request.


Another problem is with my custom validation during authentication which is 
not propagated correctly in case of OAuth2.0 implementation.

For example if user is disabled, my custom AuthenticationHandler throws an 
exception. In case of CAS Rest protocol, the exception is detected and 
transformed to specific HTTP Status code and error message e.g.
Request:
  POST https://host/cas/v2/tickets
  username=u...@gmail.com
  password=x
Response:
  Status: 469
  Body: User account is disabled
  
In case of OAuth2.0 protocol
https://lucas.c3d.com:8443/lucas/oauth2.0/accessToken?grant_type=password_id=client1=u...@gmail.com=x
Response:
Status: 500 Internal Server Error
Body: {
"timestamp": 1524128050368,
"status": 469,
"error": "Http Status 469",
"message": "No message available",
"path": "/lucas/oauth2.0/accessToken"
}
The problem is that my custom status code is propagated in the response 
body not in the response status. It is not convenient to get status 500 
Internal Server Error in this case. Error message also is not propagated 
but that is not big deal, the status code is important. Client should use 
the response status code to know what is wrong.

To get my custom error code in OAuth2.0 response I overrode the class 
org.apereo.cas.support.oauth.authenticator.OAuthUserAuthenticator and 
modified exception catch part of code from :

 } catch (final Exception e) {
throw new CredentialsException("Cannot login user using CAS 
internal authentication", e);
}

to: 

 } catch (AuthenticationException e) {
ErrorInfo error = handleError(e);
return HttpAction.status(error.getErrorMessage(), 
error.getErrorCode(), context);
 } catch (final Exception e) {
throw new CredentialsException("Cannot login user using CAS 
internal authentication", e);
}
Can you please help with this issues ? Did I do something wrong or should 
something be fixed in CAS ?

Regards,
Ivan

-- 
- 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/e5ee9585-06c1-42ae-a3db-64d11e9cbde9%40apereo.org.

[cas-user] CAS 4.1.5 SPNEGO NTLM

[Ivan Obradović]

Hello,

I'm trying to configure SPNEGO authentication and have problems with NTLM 
tokens.

So far, I successfully configured SPNEGO authentication with Kerberos 
protocol, but in some cases when KDC cannot issue Kerberos ticket, it 
issues NTLM ticket. CAS can process NTLM ticket and asks for a principal 
but the result is always NULL.
JCIFSSpnegoAuthenticationHandler is configured to support NTLM, but when it 
gets NTLM ticket and asks for principal (principal = 
this.authentication.getPrincipal(); line 88) the result is always NULL and 
there is no any error.

CAS documentation CAS 4.1.x SPNEGO-Authentication 
 
says 
that SPNEGO supports both Kerberos and NTLM. On some sites people say that 
SPNEGO does NOT support NTLM. What is true ?

Does anybody have any idea what can be wrong, or NTLM does not work with 
SPNEGO ?

Regards,
Ivan

-- 
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 post to this group, send email to cas-user@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/f0f84e2f-835d-4926-8ec5-4d072ca07196%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.