My application is running on Apache 2.0 server and my java code is deployed on Tomcat 7.0. Now i am going to introduce Single sign-on concept into my application.
Does tomcat 7.0 support SAML 2.0?
If yes please clarify , compatibility-wise what is the difference between SAML 1.0 and SAML 2.0 ?
Tomcat 7.0 does not look to have native SAML support but since you don't specify particular restricions and want to introduce Single Sign On you might be interested in Apache CXF Suite (link to SSO page), in particular Fediz plugin (see architecture ).
SAML 1.x to SAML 2.x main concerns (as protocols) are that 2.x is not backwards-compatible (new and renamed XML tags, protocol and binding changes).
If you ask which version is "better" to choose fresh, I say 2.x if you need to support both you might need a kind of converting gateway/proxy (Fediz supports 1.1 tokens but I didn't use it)
To the best of my knowledge Tomcat 7 does not have a SAML SP provider implementation. You may have a look at SAML Spring Security extension o picket link (https://docs.jboss.org/author/display/PLINK/Service+Provider+Configuration)
Related
All - I am trying to configure an HTTP connector to use Oauth1.0 instead of Basic Authentication with the Anytime Studio IDE for Eclipse. I am used to configuring the connection in the drag/drop interface of middleware, but never touching the source code. For this project, we edit the Java code to configure the connection, so I assume I will need to load some other Java class to get the Nonce and Timestamp. Does anyone have any experience/examples of implementing Oauth 1.0 in Mulesoft? in their documentation, I only see references to Oauth 2.0 and HTTP connections, not 1.0.
The most recent documentation can be found here: https://docs.mulesoft.com/connector-devkit/3.9/oauth-v1
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
The Microsoft identity team released a CTP package for WIF back in 2011 adding support for the SAML 2.0 authentication protocol.
http://www.cloudidentity.com/blog/2011/05/16/ATTENTION-ASP-NET-DEVELOPERS-SAML-P-COMES-TO-WIF/
Unfortunately the link to the Microsoft Connect site is dead. Since most WIF functionality has been moved into .NET 4.5 System.IdentityModel namespace, I was hoping to find the Saml2AuthenticationModule class there. However, I cannot find that class anywhere in the identity model assemblies.
Does anyone knows what happened to the SAML 2.0 support classes? Where they migrated to .NET 4.5 System.IdentityModel namespace? If not, is the original CTP package available somewhere?
The WIF SAML stack never made it out of CTP. Had a look around and can't find it anywhere.
It was based on WIF 3.5 so wouldn't run under WIF 4.5 anyway.
My guess it that it was removed because SAML support is non-trivial and you can get the same functionality by federating via ADFS or Azure Active Directory.
There are other libraries available - refer: SAML : SAML connectivity / toolkit.
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
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I just heard about Apache Wink, and I was wondering what differences it had compared to Jersey or JBoss RESTEasy. What can be done in one that the other two can't?
We've been using Jersey for some of our internal projects mostly for it's simplicity, but I can't really figure out what makes these other two any better that I would consider switching. Does anyone have any use-cases for which niche each of these fills?
JAX-RS Implementations
Jersey
Reference Implementation
Usually the most cutting edge
Supports true asynchronous (ie web sockets etc...) connections through either Atmosphere or 2.0 version.
Has support for Spring and standard injection containers (ie #Inject).
Glassfish bundles it.
Its much more modular than the other JAX-RS projects.
It has a kick ass URI Builder
Does not necessarily require servlet container.
Grizzly support
Netty support (very early).
Swagger support
Sort of missing OAuth 2.0 . You'll have to use other libraries.
Some MVC support through Viewables
Hosted on java.net (a minus as the site is terribly slow at times).
Licensing is based on CCDL 1.1 and GPL-v2. Please make sure you check Jersey licensing before you use it for commercial use
https://jersey.github.io/license.html
RestEasy
Much of the above but most notable supports view technologies (see HTMLEasy)
It does have asynchronous connection support
Cache support
EJB support (if your into that crap)
JBoss bundles it (I think)
Netty support
Arguably the best Spring integration (MVC handler).
Early Swagger support
More security support including early OAuth 2.0 support
Apache Wink (never used it)
I have no idea why this project exists.
Supposedly its high performance focused.
It has a client built on top of HttpUrlConnection (which is a minus... it should be pluggable like Spring RestTemplate).
Basically Wink was developed in house at some enterprise companies and then given to Apache.
Requires a servlet container.
Restlet
Very powerful but very complicated
Provides some low-level REST support
Does not require a servlet container
Apache CXF
Some interesting WADL support.
Reuse and or combine JAX-RS w/ JAX-WS
Security support
Integration w/ Spring albeit kind of nasty
Supposed Autogeneration of client stubs
Other RPC-like systems
Message Queues
RabbitMQ
ActiveMQ
Asynchronous RPC
Finagle -- from Twitter.
msgpack-rpc
My humble opinion
I know the OP asked for REST but if this is for internal communication seriously consider using either a message queue or some other asynchronous RPC (Finagle) instead of traditional REST if your requirements match those systems.
If it must be classic HTTP REST (external) I would choose between either RestEasy or Jersey as a bulk of the mind share is put into those two projects.
Also see: Rest clients for Java?
When choosing the implementation to use have this in mind: if you try to deploy a Jersey web service to JBOSS 7.1, it will not work. This error will occur:
Only one JAX-RS Application Class allowed
This is because REST Easy comes bundled with JBOSS as the default JAX-RS implementation. So, JBOSS will decide that that's the implementation you want to use and will not load another JAX-RS implementation (like Jersey). In order to fix this, you need to add the following lines to your web.xml file:
<context-param>
<param-name>resteasy.scan</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.providers</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.resources</param-name>
<param-value>false</param-value>
</context-param>
Link: https://community.jboss.org/message/744530
One of my favourite Jersey extensions is Viewables. Viewables allow you to bind your data easily to a JSP page to implement a true Model-View-Controller (MVC) architecture:
http://blogs.oracle.com/sandoz/entry/mvcj
If you're going to use JBoss 7.x you must use RestEasy, 'cause it's integrated in JBoss. To use Jersey with JBoss 7.x, you have to disable RestEasy and it is complicated!