Friday 14 November 2014
Monday 4 August 2014
The Intersection of SaaS, Enterprise Software, and Open Source IAM
The delivery of software has fundamentally changed over the last decade. SaaS applications have enjoyed broad adoption across SMB’s and large enterprises. But let’s not get carried away… not all enterprise IT services will move to SaaS. And when it comes to the keys to the kingdom — enterprise identity and credential management — SaaS clearly comes up short.
The most compelling reasons NOT to outsource your identity and access management operations to a SaaS multi-tenant cloud provider include:
Security: For many companies, a trust model where a third party holds the private keys used for signing security messages is not acceptable. For other organizations, they are bothered that if a breach occurs, they may not be notified. As a customer of a SaaS, you may not have root access on the compromised servers, handicapping your ability to figure out what happened. Net-net, SaaS authentication providers offer a trust model that is just not quite right for many organizations.
Compliance: When personal data resides on a third party’s server, ensuring that you comply with the relevant government data-protection regulations can be a challenge. At a minimum, it raises questions that need to be addressed that would not be a consideration if the authentication server is located on your organization’s private network.
Flexibility: SaaS systems are not as flexible in implementing unique business logic for authentication. There are many new authentication offerings: mobile, biometric, cognitive, tokens. Organizations don’t want to be limited to the measly number of officially supported (and probably over-priced) authentication options. Also, the workflow for authentication includes more than just the part about “how to identify the person.” API’s that perform fraud detection, central logging, intrusion detection, threat sharing and other services may need to be integrated as part of the authentication flow. For example, a company may want to present a message “You have never logged in from ___ country before, we will send you an email to confirm.” Enabling companies to implement flexible business rules for authentication has not been a strong point for SaaS authentication offerings.
Price: For customer facing applications, the “per user” pricing model just doesn’t work. It would mean a commission to the SaaS IDP on every customer sold. Even per connection metering can add up. Although the typical number of SAML relationships has been low for organizations, OpenID Connect will likely increase the number of partners.
There’s no silver bullet when it comes to implementing a comprehensive authentication and authorization (AA) service. Building and operating a stack of open source identity and access management software can be a challenge for organizations. A subscription to the Gluu Server offers a support model for open source and an alternative to SaaS: a “hybrid cloud” solution.
Gluu customers provide the IAAS service (compute, persist, network, backup). The Gluu Server is deployed on a server instance, and Gluu can provide support, deployment, configuration management, monitoring, and SLA reporting services. Unlike SaaS services, Gluu does not persist personally identifiable information on our central systems. Our primary mission is operational support for the people who are at the front line of security for their organizations.
The Gluu Server leverages standards such as OAuth2, OpenID Connect, UMA, SAML 2.0, and SCIM to enable federated single sign-on (SSO) and trust elevation. The Gluu Server is used by universities, government agencies, and companies to secure employee facing and consumer network services. Note: mostly large organizations.
So if your domain authenticates a lot of people (employees, customers or partners), if your domain has complicated authentication requirements, if you need to trust some of your partners to authenticate their own people (i.e. inbound SAML), if you have a lot of connections to applications that want to use your IDP, if you are a paranoid organization that wants more control of the PII (or you even want to actually see the code!), in general… if you have anything but plain vanilla SaaS applications and a small number of users, you may want to consider alternatives to SaaS.
The most compelling reasons NOT to outsource your identity and access management operations to a SaaS multi-tenant cloud provider include:
Security: For many companies, a trust model where a third party holds the private keys used for signing security messages is not acceptable. For other organizations, they are bothered that if a breach occurs, they may not be notified. As a customer of a SaaS, you may not have root access on the compromised servers, handicapping your ability to figure out what happened. Net-net, SaaS authentication providers offer a trust model that is just not quite right for many organizations.
Compliance: When personal data resides on a third party’s server, ensuring that you comply with the relevant government data-protection regulations can be a challenge. At a minimum, it raises questions that need to be addressed that would not be a consideration if the authentication server is located on your organization’s private network.
Flexibility: SaaS systems are not as flexible in implementing unique business logic for authentication. There are many new authentication offerings: mobile, biometric, cognitive, tokens. Organizations don’t want to be limited to the measly number of officially supported (and probably over-priced) authentication options. Also, the workflow for authentication includes more than just the part about “how to identify the person.” API’s that perform fraud detection, central logging, intrusion detection, threat sharing and other services may need to be integrated as part of the authentication flow. For example, a company may want to present a message “You have never logged in from ___ country before, we will send you an email to confirm.” Enabling companies to implement flexible business rules for authentication has not been a strong point for SaaS authentication offerings.
Price: For customer facing applications, the “per user” pricing model just doesn’t work. It would mean a commission to the SaaS IDP on every customer sold. Even per connection metering can add up. Although the typical number of SAML relationships has been low for organizations, OpenID Connect will likely increase the number of partners.
There’s no silver bullet when it comes to implementing a comprehensive authentication and authorization (AA) service. Building and operating a stack of open source identity and access management software can be a challenge for organizations. A subscription to the Gluu Server offers a support model for open source and an alternative to SaaS: a “hybrid cloud” solution.
Gluu customers provide the IAAS service (compute, persist, network, backup). The Gluu Server is deployed on a server instance, and Gluu can provide support, deployment, configuration management, monitoring, and SLA reporting services. Unlike SaaS services, Gluu does not persist personally identifiable information on our central systems. Our primary mission is operational support for the people who are at the front line of security for their organizations.
The Gluu Server leverages standards such as OAuth2, OpenID Connect, UMA, SAML 2.0, and SCIM to enable federated single sign-on (SSO) and trust elevation. The Gluu Server is used by universities, government agencies, and companies to secure employee facing and consumer network services. Note: mostly large organizations.
So if your domain authenticates a lot of people (employees, customers or partners), if your domain has complicated authentication requirements, if you need to trust some of your partners to authenticate their own people (i.e. inbound SAML), if you have a lot of connections to applications that want to use your IDP, if you are a paranoid organization that wants more control of the PII (or you even want to actually see the code!), in general… if you have anything but plain vanilla SaaS applications and a small number of users, you may want to consider alternatives to SaaS.
Friday 30 May 2014
Achilles Heel of Two-Factor Authentication
Ironically, to reset one credential, you need another. And your organization is only as secure as your weakest account recovery credential.
Today, websites use a wide array of techniques to enable account recovery. Many rely on control of an email address or a cognitive secret. Manufacturers can associate a serial number with a given customer, and require control of a device. One solution proposed is to enable account recovery based on “friend vouches.”
To use Google’s own words, account recovery is most definitely “the achilles heel” of multi-factor authentication. Organizations may want to consider solving this first, before you undertake a two-factor authentication solution. It is vulnerable to hacking humans, which is the topic of an interesting talk this year at SXSW Interactive.
What is the best way to secure account recovery?
In many organizations, hardware is going to be a long-term fact of life. It represents an ancient trust model: a physical key. Supporting hard tokens at scale is a challenge–its logistically much more difficult than scaling a mobile authentication single sign on solution. However, prices for hardware are going down, a promising standard is on the rise (FIDO), and combined with NFC, hardware tokens can be used to authenticate to both a mobile device or laptop. A lot of work needs to be done to make hardware tokens easier to use by organizations. For example enrollment is a logistical nightmare for many hardware solutions.
Many new account recovery solutions will utilize the telephone, SMS, and mobile PUSH networks. These technologies have the most potential to improve existing account recovery systems, while providing a fairly cost effective solution to support at scale.
Biometric account recovery remains a niche, but with the mainstream use of fingerprint in the iPhone, and other clever uses for voice authentication , biometric account recovery is also clearly on the rise.
Article resource - http://thegluuserver.wordpress.com/2014/05/16/how-to-benchmark-ox-for-a-large-scale-deployment/
Tuesday 7 January 2014
Go West Young Federation!
Several countries are helping businesses to start federations. For example, there is the British Business Federation Authority. At the IdentityNext conference last month in the Hague, I was lucky to hear Rainer Hörbe give a talk about the Austrian Identity Federation Authority, which aims (1) to establish and nourish multiple identity federations for B2B and B2C business cases; (2) to help business-specific federations adapt to local needs; and (3) to consolidate federations over time through the promotion of common principles, rules and procedures.
In a B2B federation, the participants are competing parties. This diagram from Rainer’s presentation highlights that identity federation is a good area for cooperation, because companies compete based on products and services and core activities, like R&D and Marketing–not on supporting activities such as infrastructure and security.
So if you are sitting there and wondering, “Does my ecosystem need an identity federation…?” The answer is probably “yes.” According to national federation authorities, not only does every ecosystem need one, but you should align with best practices in case there is a federation merger with an adjacent industry.
But starting your federation is easier said than done. This is why some governments are jumping in to help. If you are going to be the federation evangelist in your ecosystem, and you don’t have a national federation authority to give you a boost, where should you start? Following is a list of some of the things you may want to consider.
Tools
Public Website
This is the first stop for participants who are interested to learn more about your federation. You’ll need to publish information about your federation, such as the agreements, policies, procedures, participant list, metadata distribution locations, standards and other general information.
Participant Enrollment Process
New participants, both identity providers and relying parties, will want to join your federation. You need a tool to automate participant registrations, to manage the workflow for approval, and to finally render the metadata in the appropriate formats (XML and JSON). Many federations write their own software to do this. There are two open source implementations: Edugate Jagger (used by Gluu) and AAF Federation Registry.
Metadata publication and distribution
Once you have your XML and JSON federation files, you’ll need to make sure they are available. Think DNS and secondary DNS… In many cases, the federation data is updated every five minutes. So if the metadata is not available during network outages, websites may choose to deny access.
Discovery Standards
OpenID Connect based discovery defines a standard json object that is returned for .well-known/openid-configuration. The federation may want to follow this convention, and provide a JSON object that describes the functionality that is supported by the participant. You can see a sample response for OpenID Discovery from Gluu’s interop server here. Following the convention of Webfinger, the federation named “myFederation” may define a file such as this: .well-known/myFederation-configuration to enable the participants to publish information about the services provided.
User Claims / OpenID Connect Scopes
OpenID Connect defines basic user claims, which should be adopted by the federation. However, the federation may have custom requirements for standard claims. Defining standard claims at the federation drives down the cost of integration for the participants. “OpenID Connect Scopes” enable the federation to group the user claims. If a federation has defined custom user claims, they may also need to define OpenID Connect scopes to include these additional claims.
Client Claim Schema
Sometimes policy can be driven by attributes of the website. For example, if certain websites are classified as “research,” the IDP may have a different default attribute release policy.
UMA Scopes
UMA scopes are typically URLs that identify federation standards for policy evaluation. For example, the federation could define a scope “http://myFederation.org/uma/scopes/finance” (“Finance Scope”) In this way Relying Parties could submit a standard query to any authorization server to find out if that person has that permission. The policies behind this permission may vary from Participant to Participant. Participant A might specify that someone is authorized for the Finance Scope if they are in a certain Active Directory Group. Participant B may set the policy for Finance Scope based on network address and time of day. The benefit of the federation standard scope is that applications can make the same request to different authorization servers, requiring less one-off security solutions.
SAML Proxy
A SAML proxy can make it easier for a federation to roll out new websites to its IDP participants. In meshed federations, the IDP must explicitly trust the SP and release attributes. If you have thousands of IDPs in your network, it becomes hard to rollout new websites… as each IDP would have to update their configuration to add SSO. Sometimes this is desirable… especially if there is little trust in the federation to manage content. However, if the federation is trusted, using a proxy to connect to certain websites can enable people to access new content without their home identity provider having to do any incremental work.
Rules
Charter
This document provides the governance for the federation including the policies, rules, and financial arrangements.
Participation Agreement
This document is signed by the identity providers and relying parties. In some cases, an organization may be both. It also details the policies and procedures. Furthermore the Participation agreement defines the level of assurance of the authentication provided by identity providers, and the level of protection for personal data afforded by the relying parties. It can also be a good place to provide guidelines for security incident handling, threat data sharing, and other inter-domain security processes.
User Banner – Consent
Somewhere the person using the federated credentials has to agree to the rules. The best place to do this is at authentication time, so the person knows what he is getting into when he uses the federated credentials to access websites and mobile applications.
Steering Committee
Like any collaborative organization, you need to find the people who can help drive adoption in their respective communities. The steering committee should help with the formation of the Charter, provide feedback on the agreements, lead the integrations of the federation in their home organizations, and have a desire to evangelize the benefits of cooperation to industry peers.
Communication Plan
This is “marketing” for the federation. The federation may want to produce white papers, webinars, case studies, posters, conferences, regional training sessions, newsletters and other activities to get the word out about the federation. The communication plan should be a long term plan to both keep participants up-to-date, and to recruit new participants from the ecosystem.
It sounds like a long to-do list, but like any journey, the hardest part is the first step. If you want some help along the way, you may want to schedule a meeting with Gluu. We are helping to catalyze several federations around the globe.
In a B2B federation, the participants are competing parties. This diagram from Rainer’s presentation highlights that identity federation is a good area for cooperation, because companies compete based on products and services and core activities, like R&D and Marketing–not on supporting activities such as infrastructure and security.
So if you are sitting there and wondering, “Does my ecosystem need an identity federation…?” The answer is probably “yes.” According to national federation authorities, not only does every ecosystem need one, but you should align with best practices in case there is a federation merger with an adjacent industry.
But starting your federation is easier said than done. This is why some governments are jumping in to help. If you are going to be the federation evangelist in your ecosystem, and you don’t have a national federation authority to give you a boost, where should you start? Following is a list of some of the things you may want to consider.
Tools
Public Website
This is the first stop for participants who are interested to learn more about your federation. You’ll need to publish information about your federation, such as the agreements, policies, procedures, participant list, metadata distribution locations, standards and other general information.
Participant Enrollment Process
New participants, both identity providers and relying parties, will want to join your federation. You need a tool to automate participant registrations, to manage the workflow for approval, and to finally render the metadata in the appropriate formats (XML and JSON). Many federations write their own software to do this. There are two open source implementations: Edugate Jagger (used by Gluu) and AAF Federation Registry.
Metadata publication and distribution
Once you have your XML and JSON federation files, you’ll need to make sure they are available. Think DNS and secondary DNS… In many cases, the federation data is updated every five minutes. So if the metadata is not available during network outages, websites may choose to deny access.
Discovery Standards
OpenID Connect based discovery defines a standard json object that is returned for .well-known/openid-configuration. The federation may want to follow this convention, and provide a JSON object that describes the functionality that is supported by the participant. You can see a sample response for OpenID Discovery from Gluu’s interop server here. Following the convention of Webfinger, the federation named “myFederation” may define a file such as this: .well-known/myFederation-configuration to enable the participants to publish information about the services provided.
User Claims / OpenID Connect Scopes
OpenID Connect defines basic user claims, which should be adopted by the federation. However, the federation may have custom requirements for standard claims. Defining standard claims at the federation drives down the cost of integration for the participants. “OpenID Connect Scopes” enable the federation to group the user claims. If a federation has defined custom user claims, they may also need to define OpenID Connect scopes to include these additional claims.
Client Claim Schema
Sometimes policy can be driven by attributes of the website. For example, if certain websites are classified as “research,” the IDP may have a different default attribute release policy.
UMA Scopes
UMA scopes are typically URLs that identify federation standards for policy evaluation. For example, the federation could define a scope “http://myFederation.org/uma/scopes/finance” (“Finance Scope”) In this way Relying Parties could submit a standard query to any authorization server to find out if that person has that permission. The policies behind this permission may vary from Participant to Participant. Participant A might specify that someone is authorized for the Finance Scope if they are in a certain Active Directory Group. Participant B may set the policy for Finance Scope based on network address and time of day. The benefit of the federation standard scope is that applications can make the same request to different authorization servers, requiring less one-off security solutions.
SAML Proxy
A SAML proxy can make it easier for a federation to roll out new websites to its IDP participants. In meshed federations, the IDP must explicitly trust the SP and release attributes. If you have thousands of IDPs in your network, it becomes hard to rollout new websites… as each IDP would have to update their configuration to add SSO. Sometimes this is desirable… especially if there is little trust in the federation to manage content. However, if the federation is trusted, using a proxy to connect to certain websites can enable people to access new content without their home identity provider having to do any incremental work.
Rules
Charter
This document provides the governance for the federation including the policies, rules, and financial arrangements.
Participation Agreement
This document is signed by the identity providers and relying parties. In some cases, an organization may be both. It also details the policies and procedures. Furthermore the Participation agreement defines the level of assurance of the authentication provided by identity providers, and the level of protection for personal data afforded by the relying parties. It can also be a good place to provide guidelines for security incident handling, threat data sharing, and other inter-domain security processes.
User Banner – Consent
Somewhere the person using the federated credentials has to agree to the rules. The best place to do this is at authentication time, so the person knows what he is getting into when he uses the federated credentials to access websites and mobile applications.
Steering Committee
Like any collaborative organization, you need to find the people who can help drive adoption in their respective communities. The steering committee should help with the formation of the Charter, provide feedback on the agreements, lead the integrations of the federation in their home organizations, and have a desire to evangelize the benefits of cooperation to industry peers.
Communication Plan
This is “marketing” for the federation. The federation may want to produce white papers, webinars, case studies, posters, conferences, regional training sessions, newsletters and other activities to get the word out about the federation. The communication plan should be a long term plan to both keep participants up-to-date, and to recruit new participants from the ecosystem.
It sounds like a long to-do list, but like any journey, the hardest part is the first step. If you want some help along the way, you may want to schedule a meeting with Gluu. We are helping to catalyze several federations around the globe.
Subscribe to:
Posts (Atom)