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.
Web Server Filter / Reverse Proxy
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.An example of the UMA Apache directives:
- UmaAuthorizationServer gluu.example.com
- UmaResourceName “Protected Part of My Website”
- UmaGetScope “https://example.com/uma/read”
- UmaPutScope “https://example.com/uma/write”
- UmaPostScope “https://example.com/uma/create”
- UmaDeleteScope “https://example.com/uma/delete”
- UmaSentUserClaims “issuingIDP;givenName;mail;uid”