Social logins using Oauth2 have become a industry standard. It has revolutionized the way sites share data and has allowed users to quickly access new applications without having to create a new set of credentials. This article gives an example of why OAuth2 was invented and provides a working example of a Spring Security 5 application integrated with Google.
I’ve been in the software development business for a long time and I can’t tell you how many login screens with authentication logic I have implemented. You might say that one of the most prevalent user stories is the need to log in and securely authenticate a user’s access to an application.
Here at Keyhole Software, we have implemented countless login and authentication approaches for applications, along with simple to sophisticated authorization schemes enforcing access control of applications. Of course, you can utilize the single sign-on type of technologies such as OAuth or OpenID, which offload the development of a login UI and the logic for authentication/authorization. However, these standards are not always utilized in enterprise environments. Many enterprises will have a single authentication mechanism that exploits a federated operating system network such as LDAP. A login UI still has to be created and authorization rules still have to be applied to each application.
Over the last few years, we have helped organizations transition away from monolithic-based applications to isolated microservice-based architectures. With Microservices, authentication and authorization logic is now spread across many decoupled distributed processes. It was a bit simpler with monolithic architectures as only a single process is authenticated and contains access control rules defined.
In this blog, we discuss a design pattern for authorization and authentication for use in a distributed microservices environment.
TL;DR: Add OWASP Dependency-Check to your build process to get insight into your dependency vulnerabilities.
Recent major data losses and security vulnerabilities in open source frameworks *(and the applications that use them)* have caused the companies that use those frameworks to have elevated concerns regarding vulnerabilities. The elevated awareness is for good reason, too. After all, no one wants to be the next one to lose sensitive data, be the punching bag of others, or be the example of what *not* to do security-wise.
If you happen to be in a group that doesn’t have any open source vulnerability reporting, OWASP Dependency-Check may be your short-term answer to get at least something in place. Adding OWASP Dependency-Check into your build process takes a relatively low effort. Other than not having the technology that stack Dependency-Check can help you with, there isn’t a reason not to at least add Dependency-Check to give a little insight into your open source dependencies.
When I heard that the Struts Open Source framework played a role in the recent Equifax hack, I wanted to do some research to understand how it happened. Struts is a commonly-used Java framework that I have applied in the past. And I’m not alone in that: it is reported that in 65% of Fortune 500 companies currently implement Struts in some way.
So, I did a little digging and performed a thought experiment asking myself the following question: “If Equifax had a pure-play Microservices Architecture in place, would it have solved the problem?”
Attention: The following article was published over 5 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.At Keyhole, we have published several blogs about Microservices. We’ve talked about architectural patterns used in a Microservices environment such as service discovery and circuit breaker. We’ve even posted blogs on platforms …
- Page 1 of 2