Due to tightening regulations, increased usage of third-party applications, and the sheer volume of breaches caused by weak credentials, single sign-on (SSO) is increasingly becoming a ubiquitous enterprise security requirement. Many organizations also need to centralize policies to control access to valuable API’s or Web resources.
SaaS services seem like a good option at first, but if you have a complex integration with a legacy backend, or you’re just a paranoid security nerd, the DIY open source approach has distinct advantages with regard to cost, security and privacy. In this blog, we’ll discuss the two ways to protect an application using a centralized access management platform like the Gluu Server.
How do you control access to a home grown application? For many organizations, purpose-built applications provide a competitive advantage. Two application security design patterns have emerged. Which one to pick, depends on the trade-off between easier devops, and how deeply you want to integrate centralized security policies into your application.
This is the tried and true approach since the introduction of Netegrity Siteminder in 1998–install an Apache Web Server “mod”, or an IIS “ISAPI Filter” to enforce the presence of a token in a HTTP Request. If no token is present, the Web server may re-direct the person, or return a meaningful code or message to the application. Your devops team will love this approach–they can just manage the web server configuration files. It will be crystal clear to them what policies apply to what URLs.
To require SAML authentication in a web server, Gluu recommends the mod_shib. If you’d prefer to use the Gluu Server’s OpenID Connect interfaces, we recommend mod openidc. Gluu is working on an apache module for UMA 1.0, a new OAuth2 based profile that defines RESTful, JSON-based, standardized flows and constructs for coordinating the protection of any API or web resource…. stay tuned but it should be available by the end of Q2 2015.
In the hypothetical example above, the Apache server would require different UMA scopes to perform different HTTP methods in the /protected folder. User claims (or attributes) gathered in the Apache server could also be sent. In the example above, perhaps a SAML authentication happened. The attributes returned by the SAML IDP can be sent to the UMA Authorization Server.
Libraries exist for SAML, OpenID Connect and UMA in many languages, for example Java and Python. If you want to use UMA or OpenID Connect, and no library exists, your application could use the Gluu OXD server as a mediator. Your application would use local sockets (non-encrypted) to communicate with OXD using a simple JSON protocol.
In general, calling the API’s directly will enable your developers to make your application “smarter.” For example, you could implement transaction level security more easily. This can have a positive impact on usability. Giving developers more ability to leverage centralized policies may also increase re-use of policies, and ultimately result in better security for a number of reasons.
One more consideration: many developers find it annoying to test the code if a security system relies on a Web Server plugin. It hasn’t stopped the wide adoption of Web plugins, but of course we want to make those developers happy!
Both approaches will work, the question is which is a better solution for your requirements. Schedule a meeting with us if you would like to discuss your project requirements and we can help steer you in the right direction. We can also provide referrals to certified Gluu partners for design and integration services as needed.