Recently in Identity & Access Management Category

Locking down PingFederate with Jetty Rewrites

| No Comments

PingFederate is a very secure product, as a Federation server and STS it can operate in many different roles and situations. One particular scenario is when direct access to certain endpoints need to be exposed to the outside world.

Sometimes when using PingFederate it is desirable to be able to terminate SSL/TLS directly. This of course limits the possibilities to block un-used endpoints to the outside in a reverse proxy since it cannot investigate the traffic.

This may be to protect from internal attacks on the company network, or when some endpoints need to be exposed to the outside world. In such scenario it is of course not recommended to allow any source IP to communicate with the federation server, but in either case, the security of the client is out of the hands of the organization. In these cases measures can be taken to lock PingFederate down even further.

PingFederate runs on Jetty, and much of the configuration is done in Jetty configuration files and with Jetty configuration parameters.

Jetty has a module called Jetty Rewrites which essentially lets the request be rewritten or redirected before its passed along in the handler stack.
Unfortunately the rewrite modules is not shipped with the Jetty setup that PingFederate ships with, but luckily it's very easy to add.

Simply download the jetty-rewrite-XYZ.jar where XYZ corresponds with the Jetty version your PingFederate installation is running on. Note that the version must correspond EXACTLY for the Jetty runtime to pick it up.
Install the jar in <PF>/lib where the rest of the jars for jetty are located.

To enable the rewrite capability edit the jetty.start.ini file in <PF>/bin and update the following:
Add 'rewrite' to the end of the OPTIONS list:

OPTIONS=Server,jsp,resources,ext,plus,annotations,jmx,rewrite

Add etc/jetty-rewrite.xml to the bottom of the file after etc/jetty-admin.xml.

Create the rewrite rules

Now the preparations are done. To actually do some rewrites create a file called jetty-rewrite.xml and place it in the <PF>/etc directory.

A common example would be to lock down the PingFederate box to only operate as an OAuth2 server. In such case the following rules would block everything except the /as/authorization.oauth2 and the /as/token.oauth2 endpoints.

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="RuntimeServer" class="org.eclipse.jetty.server.Server">
   
  <Get id="oldhandler" name="handler"/>
   
  <Set name="handler">
    <New id="Rewrite" class="org.eclipse.jetty.rewrite.handler.RewriteHandler">
      <Set name="handler"><Ref id="oldhandler"/></Set>
      <Set name="rewriteRequestURI">true</Set>
      <Set name="rewritePathInfo">true</Set>
      <Set name="originalPathAttribute">requestedPath</Set>
      <!-- Add rule to protect against IE ssl bug -->
      <Call name="addRule">
        <Arg>
          <New class="org.eclipse.jetty.rewrite.handler.MsieSslRule"/>
        </Arg>
      </Call>
      <!-- =============================== -->
      <!-- Response rules                  -->
      <!-- =============================== -->
      <!-- Response rule for failed requests -->
      <Call name="addRule">
        <Arg>
          <New class="org.eclipse.jetty.rewrite.handler.ResponsePatternRule">
            <Set name="pattern">/not-allowed</Set>
            <Set name="code">405</Set>
            <Set name="reason">Not Allowed</Set>
          </New>
        </Arg>
      </Call>
      <!-- ================================= -->
      <!-- Allowed endpoints                 -->
      <!-- ================================= -->
     
      <!-- Allow -->
      <Call name="addRule">
        <Arg>
          <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/as/authorization.oauth2/*</Set>
            <Set name="replacement">/as/authorization.oauth2</Set>
            <Set name="terminating">true</Set>
          </New>
        </Arg>
      </Call>
      <!-- Allow -->
      <Call name="addRule">
        <Arg>
          <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/as/token.oauth2/*</Set>
            <Set name="replacement">/as/token.oauth2</Set>
            <Set name="terminating">true</Set>
          </New>
        </Arg>
      </Call>
      <!-- ========================================== -->
      <!-- Deny rules                                 -->
      <!-- ========================================== -->
      <!-- Blocks all -->
      <Call name="addRule">
        <Arg>
          <New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule">
            <Set name="regex">/(.*)</Set>
            <Set name="replacement">/not-allowed</Set>
            <Set name="terminating">true</Set>
          </New>
        </Arg>
      </Call>
    </New>
  </Set>
</Configure>

Helping Secure the Cloud and Mobile

| No Comments

In my last post, I talked about the new research out from AMD wherein security is said to still be the number one concern that cloud computing adopters have. To address these risks, I talked about how existing Identity and Access Management (IAM) practices, procedures, and infrastructure need to be extended to include these new cloud services. In this way, organizations can determine how best to answer the questions who are you and what are you allowed to do. The first can be done by reusing existing authentication systems and federating the identified users to the cloud; the latter can be done by provisioning authorization policies into the sky for enforcement and by pulling back cloud audit logs for centralized analysis.

At Twobo, we are helping organizations in all industries ensure that their Identity Management (IdM) services can secure on-premises systems as well as public, private, and hybrid clouds. We deliver this help in the following ways:

  1. Advice, knowledge, and expertise gained from years of developing and supporting IAM systems and from working w/ numerous organizations worldwide in the adoption of cloud computing.
  2. Pre-integrated, best of breed software from leading vendors in the field of cloud security, including Ping Identity, Axiomatics, UnboundID, and others.
  3. Integration of these and other applications into world-class production systems that scale to millions of users and thousands of apps.
  4. Management and support services needed to ensure peak performance of the critical cloud identity management solutions organization create from such knowledge and products.

Our years of experience building software in high-security industries have conditioned the way we think about mobile and the cloud. Our deep knowledge of digital identity coupled with our past experiences allows us to help organizations that are struggling to overcome the risks associated with today's hyper distributed software systems. By meeting with over a hundred organizations in all industries around the world in the last two years alone, we have seen the common struggles resulting from cloud and mobile computing adoption. We have helped these companies overcome the barriers, and have devised workable solutions based on exclusive knowledge and partnerships with specialized security software vendors that address the security concerns of the cloud's naysayers.

In our upcoming blog posts, we'll explain more about how we're helping our customers and share more about our experiences building secure information systems. Till then, please feel free to contact us, leave a comment, or DM us on Twitter to find out more about how we can help you secure the cloud and your mobile apps.

Federation, Entitlement Management and the Cloud

| No Comments
Now that I'm in Sweden, it was only a matter of time before I bumped into the guys at Axiomatics. When I was in Stockholm the other day, we had fika and talked about federation, entitlement management, financial services, and the upcoming EIC conference. While we sipped our coffee, we discussed what it would look like to put PingFederate and Axiomatics Policy Server (APS)together to form a best-of-breed solution that provides organizations like financial institutions with the ability to easily get prospects into the customer corridor by leveraging identities that they already have while simultaneously removing authentication and authorization from their line of business (LOB) applications.

Before our bullar were done, we had come up w/ an architecture that used PingFederate's Cloud Identity Connectors to reduce the number of steps prospective retail banking customers have to perform when deciding whether or not to do business with a particular financial institution. Using these, prospects can connect with Facebook, Google, Twitter, or other social networks to easily provide basic information about themselves (e.g., the country they live in). With this, a bank can show the prospect personalized and targeted information such as local contact phone numbers, state- or country-specific terms of service, local market news (e.g., exchange rates for the Krona if in Sweden or USD if in the States), and locations of nearby branches and ATMs. Using existing identities, organizations can provide Web surfers with more relevant information, helping them find what they need to decide to begin doing business with the provider.

In the banking scenario that we were chatting about as well as in many others, security in critical. In such cases, social sign-on, though helpful in reducing friction and increasing conversion rates, cannot provide a high enough level of assurance (LoA) that a person really is who they say they are. To overcome this, after someone signs up for an account, a bank would verify their physical identity and then provide them w/ a new digital identity. Using the new one and not a social network identity, the customer could gain access to higher value assets like online banking. This account would be stored in a directory maintained by the financial institution. Even with this and the support for all the different protocols used by the various social networks, our architecture was simple because PingFederate supports so many types of identity providers. The overall scheme we cooked up is shown in the following sketch: