I am beginner in using CAS and i'm using it in one of my project to use its Single Sign On services. Till now i have implemented Single sign on, I have one JAVA client and a PHP Client. But for using Single Sign Out functionality i configured my running CAS according to CAS documentation. I have done all the changes in the deployerConfigContext.xml of my working CAS. My CAS is up running, but on logging out it doesn't show any SAML logout request. I'm using Official PHP Client and Java Client made by me. I think it may be due to these lines which i'm not able to configure it in my Client side.
The way the notification is done (back or front channel) is configured at a service level through the logoutType property. This value is set to LogoutType.BACK_CHANNEL by default.
I'm not able to understand by this line where actually i had to set the Logouttype to BACK_CHANNEL, if its my Client then why is it that it is set to BACK_CHANNEL by default as a Client can be made by anyone.
Any help is highly appreciated.
Thanks in Advance.
Take a look at the jasig documentation: http://jasig.github.io/cas/development/installation/Logout-Single-Signout.html
When a CAS session ends, it notifies each of the services that the SSO
session is no longer valid, and that relying parties need to
invalidate their own session.
This can happen in two ways:
CAS sends an HTTP POST message directly to the service ( back channel communication): this is the traditional way of performing
notification to the service.
CAS redirects (HTTP 302) to the service with a message and a RelayState parameter (front channel communication): This feature is
inspired by SAML SLO, and is needed if the client application is
composed of several servers and use session affinity. The expected
behaviour of the CAS client is to invalidate the application web
session and redirect back to the CAS server with the RelayState
parameter.
And the important part:
Usage Warning!
Front-channel SLO at this point is still experimental.
So your SSO server sends a request to the application directly. The authenticator recognizes that this request is a special one and logouts the referenced user.
Update:
Take a look at the following links:
https://wiki.jasig.org/display/casum/single+sign+out
https://github.com/Jasig/cas/blob/6c3df3a5f42d2d8b771ba773aeda3ba5a4c525e3/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/applicationContext.xml
https://github.com/Jasig/cas/blob/6c3df3a5f42d2d8b771ba773aeda3ba5a4c525e3/cas-server-core/src/main/java/org/jasig/cas/logout/LogoutManagerImpl.java
Did you accidantly remove or overwrite your logoutManager declaration in your applicationContext? Is there an logoutManager bean in your running spring context?
I would start by setting break points in the handleLogoutForSloService, performBackChannelLogout and performLogout methods of LogoutManagerImpl.java.
Are they beeing called?
Can you step through them?
Is performBackChannelLogout called?
Is this.httpClient.sendMessageToEndPoint(msg) in performBackChannelLogout successful?
If you are logged on to 2 services, performBackChannelLogout should be called twice with both service urls.
Related
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I'm currently making tests with the CAS server 3.5.2 and I'm facing
problems with the logout.
My knowledge in these topics is limited and I don't manage to go further on
that point.
I installed a CAS server and I've got 2 instances of the same java
application that point to that CAS server (appologize if I don't use the
adecuates terms).
So, when I access to the protected resources of my client aplication, I'm
redirected to the CAS login page, I check in my DB if credentials are ok
and then I access the resource. Then, if I access to the same protected
resource from the second instance of the client application I'm not
redirected to login page. That's perfect.
The problem is situated in the logout. To do so, I first execute a
session.invalidate() and access to the CAS logout page. It's ok because,
from the application from which I logged out, I must login again to access
the protected resources. On the other side, the second application remains
connected and I can access the protected resources without login again.
Well, I know that the session.invalidate() is local to the first
application but I thought that CAS server would have "broadcasted" the
desconnexion to the other application but no.
Is there somebody who can give me experience feedback for the single sing
out topic ?
First make sure that SSO is enabled in the CAS properties file, if not make sure the SSO Listener is enabled in the clients.
If they are enabled then my guess would be the issue is in either the LogoutManagerImpl.java or SamlCompliantLogoutMessageCreator.java files.
The SSO in CAS is performed through the back-channel by transmitting a SAML XML message.
I had an issue with the SSO function last year only to find out that the XML message being broadcasted had an error that prevented it from being parsed.
Finally I solved...
In web.xml, the order of filters is important. Filters for Single-sign out must be placed at the begining.
See that section https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.1#CASClientforJava3.1-OrderofRequiredFilters
I am building a RESTful web service using ASP.NET web API. I've read that it isn't very RESTful to use session authentication since a "login" request is required before any other request can be successfully made. In addition, it requires the client to maintain state.
My original design was to have the client call a "login" request using basic HTTP authentication over SSL. The web service would then verify the credentials and respond with a session key. The client then uses that session key to sign all subsequent requests. When the web service receives any of these requests it looks up the session key, signs the request in the same way, and checks if the two signatures are equal.
Is it possible to avoid this session authentication without having to send the username/password with each request? The credential verification does not happen within the web service (it is routed to another server that maintains users). I'm concerned that performance will be affected if I need to validate each request.
It's not possible. You either store the state or get the credentials with each request. The second option is what you would want with your HTTP API.
Depends what you mean with "validate"
you could e.g. cache the hash(username+password) in your application. And on subsequest requests check if the cached entry still exists. This way you can save roundtrips to your backend store.
How do I add a security layer to my REST application, I am both in control of my server and client,
I am using NANCY as a server and RESTsharp as client.
I have hard time understanding how to make calls secure if REST support to be stateless.
Thank you
Christian's comment may be sufficient for your needs. It shows how to use the Nancy add-ins for Basic or FormsAuth and RESTSharp does support Basic auth right out of the box.
I've been building a Nancy driven REST API at work for quite some time now, we've used both RESTSharp as well as plain HTML+JS as clients and we chose to implement our own session based authentication (partly because those add-ins didn't exist when we implemented). However what is nice about it, is how simple it is to use regardless of what the client supports. I'll quickly explain how it works.
The client sends their username and password (or if you like, identifier and secret key) to create a new session resource using POST /sessions (use HTTPS). This resource contains a session key which can be used for subsequent calls. The session expires after X minutes of inactivity.
Each call made to the service requires a valid session key (except creating a session). The key is provided either as a cookie or in the query string. When using RESTSharp we usually set this as a cookie and just keep reusing it unless it's expired.
Finally, the session can be destroyed by calling DELETE /session/{key}.
This is a simple, but effective (assuming HTTPS) way to secure a REST API.
Alternatively you could implement OAuth, which RESTSharp also apparently supports out of the box.
I have a set of REST services that I ONLY want my web application to consume. I do not want my users to be able to use their credentials and have the services consumed by a third party application (since my data is paid for). I there a way to ensure that only my javascript can make calls to the services from a browser that cannot be spoofed (request headers and user agent detection for instance will not work.)
This is probably more of a creative problem.
I am also providing a REST API. I use a mix of an API Key which is always static an can be spoofed. Next is a signature which will be generatet on clinet side and prooved on server side on each request. The signature is build by a combination of all parameters AND a secret password. this prevent a man in the middle from executing for example the same call with another parameter.
Only bad is that a spoofed request can be sent again. I dont know already how to prevent that.
Signed client certificates and HTTPS.