I need to use CAS to authorize access to a web application built with the Play! 2.x framework. Play! 1.x has a module for CAS (http://www.playframework.org/modules/cas); Play! 2.x does not (that I've been able to find).
Does anyone have sample code they would be willing to share? Tips/tricks/gotchas? Otherwise, I'll dig into the 1.x module and see if I can adapt it to work with 2.x.
I'm developing with Scala.
Thanks,
Byron
[Update]
I also asked this on the Play! google group. James Roper replied to say:
Well, Play 2 is quite different from Play 1, so don't expect it to be easy to port. You have two general approaches:
1) The easy but not as good approach, use the official CAS Java client to make blocking calls on the CAS server. Make sure your Akka thread pools are tuned for this, by default they give you one thread per core, if you go with this approach you probably want 100-200 threads all up, otherwise other requests are going to get blocked by requests that are trying to talk to the CAS server, especially if the CAS server is ever slow to repsond.
2) The hard but better approach, implement your own non blocking CAS client using the Play WS API. The protocol is described here: http://www.jasig.org/cas/protocol
My current thought is to put an Apache server in front of Play to do the CAS authentication.
I've created what you're looking for : a Play 2.x client in Scala and Java which supports OAuth/CAS/OpenID/HTTP authentication and user profile retrieval : https://github.com/leleuj/play-pac4j.
It completely supports the CAS protocol :
CAS 1.0 / 2.0 / SAML valition + proxy ticket validation
logout request
CAS proxification
Related
This may be a very simple issue but is (I think) complex to explain so, please bear with me.
We have a WCF API (written in C#) on our server which attaches to third-party APIs (a sort of one-stop place, if you will). These use a mixture of OAuth and certificates for security. The idea is that we don't have to put (the third party) certificates / security on all of our servers, just the one.
Therefore, the plan is for an application on one server to call the API on this server which calls the third-party API. This seems to work for all but one third-party.
If I use the Visual Studio (2017) inbuilt WCF Test Client on our API, it works fine. If I try to use our API from another application (by adding a service reference) even on the same server it fails with the above message.
Our API does not (yet) use https.
The plan is for use to release our API to others so we can't share any certificates / logins with them - this is the underlying reason for our API.
I have done a lot of Googling about this and all of the answers seems to point to the certificate has to be on the calling application which would seem to defeat the object of our "catch all" API
I have probably not explained this very well - sorry. Maybe the issue could be summed up as "how do I stop the security being "passed down" to the calling application?"
Seems that the culprit was the Application Pool Identity that "Our" API was running under. I changed that and now everything works as I would expect it to :)
Context:
I'm researching about how to easily implement SSO for an enterprise on-premise Service Provider to enable SAML and OIDC both. I came across multi-provider wrappers but I wasn't able to find python(tornado) specific ones.
Research:
The only active one I found is this but as it’s mostly for social and looks like it doesn’t support saml.
This link mentions some client based python wrappers like sanction, rauth but both doesn't support SAML
Apart from wrappers I also looked at dev tools provided by oneLogin for SAML protocol.
https://www.onelogin.com/resource-center/saml-toolkits
Python SAML OneLogin - How to support multiple Identity Providers
Questions:
which are the multi-provider authentication wrapper for python enterprise apps?
Are there other options apart from the ones mentioned above to ease the SP development?
Could I potentially use a wrapper like python-social-auth for OIDC support and OneLogin devtool for SAML support?
I'm a Product manager and not a dev. I have been researching a lot but to no avail.
python-social-auth supports SAML and OIDC. It supports multi-tenancy as well (overriding the default strategy).
I recommend you to use it rather than trying to implement them yourself if you want to save time/money or if your dev team has no much idea about authentication in general.
I am in need of a solution for using ADFS 3.0 identities in a ASP.NET Core 2 Web Api application. The Windows Enterprise Support team at my organization has informed me that they are only familiar with SAML or WS-Fed based relying parties within ADFS, and are not interested in allowing me to help them configure OAuth, which I could consume directly within the application. As far as I am aware, neither SAML nor WS-Fed are compatible with anything currently available targeting netcore or netstandard.
I've been looking at Identity Server 4, and it's so-called "Federation Gateway" functionality, but I can't find much in the way of documentation. Is this something that could be useful for my use case? I'm guessing that it's only set up to interface via OAuth or OpenID, but I could be wrong.
I've also looked at using Amazon Cognito as the middleman to issue JWTs based on the SAML response, but after I got a proof of concept working with this configuration, I realized the cost at $0.45/MAU is prohibitively high, as the application will have around 10-15k regular users.
If Identity Server isn't the solution, are there any other similar "Federation Gateway" type solutions available as preferably open source/free software? Even if the solution wasn't .NET-based, I'd be interested in looking at it. I'm toying with the idea of building something like this in Java or Ruby as a last resort.
As of version 2.0, IDS4 can be a WS-Fed relying party. This would allow it to act as a middleman between ADFS and OIDC/OAuth RPs.
This vid from the IDS4 guys covers the available options: https://vimeo.com/254635632
It's also worth noting that you can run ADFS 2016 servers in a 2008R2 or higher domain and that natively supports OpenID Connect but given what you've said about your internal "support" team, deploying IDS4 may be a better option, although probably more work.
Just for completeness, the issue with WS-Fed was cyptographic support in .NET Core. This is now resolved so WS-Fed is supported.
SAML support is available via Sustainsys or Rock Solid Knowledge.
You can implement SAML 2.0 federation with AD FS 3.0 in ASP.NET Core 2.1 using the ITfoxtec Identity Saml2 package. NuGet package: https://www.nuget.org/packages/ITfoxtec.Identity.Saml2.MvcCore/
Project https://itfoxtec.com/IdentitySaml2 and code samples https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test
Is there a single sign-on solution with completely RESTful API installable on my server? I have looked at OpenAM, which have some of the API available through HTTP/JSON, but not all (and seems too heavy, but if it had all the API, I'd not care).
Do you know of solution for authorization, authentication and identity management that can be used for single sign-on and has all (maybe without setting admin password and such critical issues) its API available though HTTP(S)/JSON?
I have no need for Java API etc., HTTP(S)+CLI for setup is only thing I look for. That is, I doin;t realkly care what the solution is implemented in (no need for Java EE etc.) as far as it does its job and it is secure.
Have you seen Mozilla's new Persona solution built on BrowserID? It does a lot, but it's hard to know if it's sufficient for you without more details about how integrated you need the authorization to be.
You might want to look at Stormpath. They're the largest identify management service (for developers) -- and they are all REST + JSON API backed.
I have a web service that accepts CAS proxy tickets over HTTP Basic authentication headers via Spring Security. How do I perform integration testing with my client since there seems to be no programmatic way to fetch CAS tickets?
Since the CAS setup is one of the more tricky aspects of the project configuration I really need that to be part of our automated integration tests but I have hit a roadblock.
You be interested in the CAS RESTful API: https://wiki.jasig.org/display/CASUM/RESTful+API
The RESTful API follows the same basic protocol as the original CAS2 protocol, augmented with some additional well-defined resource urls. This is particularly helpful for applications that need to programmatically access CAS.
Hope this helps.