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.
Monday, 16 December 2013
Gluu Web Authentication / SSO Protocol Adoption Predictions
Its hard to make accurate predictions about adoption for SSO protocols. Its impossible to make a detailed model when the known inputs are so vast. With that inherent disclaimer about the difficulty of forecasting, the following graph represents Gluu’s view about the likely adoption and un-adoption of three very important web authentication standards: SAML, CAS, and OAuth2 (specifically OpenID Connect).
SAML
It makes sense to start any conversation about web authentication standards with the grand-daddy of Web SSO, the Security Assertion Markup Language–SAML. This is the current leading standard for enterprise inter-domain authentication. It is widely supported by off-the-shelf software, and major SaaS vendors like Google, SalesForce, WorkDay, Box, Amazon, and many others. SAML is the basis for extensive B2B, government and educational networks around the globe. Gluu’s prediction is that providing SAML endpoints and services will be critical for domains for years to come. In the next 15 years or so, organizations will look to consolidate on OAuth2 based trust networks, and will look to end-of-life and de-commission SAML relationships.
CAS
The “Central Authentication Server” defined one of the first Web SSO protocols. Its a simple to use API, and supported by several open CMS platforms. Backed by LDAP, it was a good choice for many organizations to centralize username / password authentication. It also allowed access control based on network address, to restrict which servers can use the enterprise web authentication service. With the availability of newer, more functional authentication standards, like SAML and OpenID Connect, new applications should be directed away from CAS. Older applications should also be asked to upgrade to one of the newer protocols. CAS was great, but there are better options now.
OpenID Connect
OpenID Connect is a profile of OAuth2 that provides several services related to authentication. In years past, federation experts thought OpenID would be ubiquitous. Then a smaller subset of federation experts thought OpenID 2 would be ubiquitous. However, the community has coalesced, and now a large group of federation experts are predicting that OpenID Connect will become ubiquitous. Its a risky position, but it holds up when you look at some simple indicators:
Support of large consumer IDPs: Google, Microsoft, Yahoo probably Facebook
Consolidation of several protocol communities such as OpenID, Oauth2, WS-*, a subset of the SAML community.
Move in consumer market to JSON/REST Authentication API’s
Explosion of mobile applications requiring better authentication API’s for non-web interactions
Expanded role of a “client” acting as an agent of the Person to access Web APIs
New standards that are building on OpenID Connect authentication, such as UMA and the new OpenID Connect Native SSO working group.
Even Scott Cantor has acknowledged at InCommon Camp that Shibboleth 3.0 is being designed to make it easier to support OpenID Connect in the future!
So we’re going out on a limb here… and predict that OpenID Connect is actually going to catch on this time. We are also perhaps going to help our own cause by providing a scalable, production quality open source implementation of OpenID Connect: oxAuth.
If anyone disagrees or agrees with the admittedly arbitrarily drawn graphs above, feel free to comment below!
Tuesday, 26 November 2013
Postcard from IdentityNext 2013
IdentityNext is a unique conference that pulls aspects from several of the identity events I’ve attended over the years. As only a handful of Americans attend, it reminded me of Kuppinger’s EIC (European Identity Conference). There were delegates from many Western European counties, for example Sweden, Denmark, France, Germany, Austria, Spain, Belgium, the Netherlands (of course), England and probably a few more. The focus on privacy reminded me of the PII (Privacy, Identity, Innovation) which is held several times around the US. And finally, it was the second conference I attended this year that had an “un-conference” portion, inspired by IIW (Internet Identity Workshop).
It was a great honor for me to deliver the opening keynote. I wanted to give a general interest talk about federations, an introduction to OAuth2, and describe how these two technologies could be combined to the net benefit of society. I was a little tense, especially as I’d never attended this conference. My slides are here. I was amused that Martin Wegdam quoted me on Twitter as apologizing for previous XML identity standards. I was not really serious… As Andre Durand says, “Identity” is a big and complex domain of knowledge. If we (as in the global community of identity architects) had figured “it” out on the first try, it would have been a miracle. Defining standards for identity has been an iterative process. And 13 years later, I think the work done on OpenID Connect puts us on the verge of a good technical standard for one aspect of Identity–authentication. “Connect” has achieved something even more elusive: consensus.
One of the best talks was given by author, journalist and teacher Pernilla Tranberg. She presented an up-to-date view of the current state of online privacy, and some pragmatic strategies we can consider to achieve more control of our personal data. For example, don’t use Google search… use “Start Page”, which strips out all the tracking cookies that sell to advertisers the interested implied by your Internet searches. Also, advise your kids to sign up for Facebook using a different name so they can start their adult life with a clean slate.
One of the most amusing talks was given by Mike Chung from KPMG on the topic of predications. He recommended a number of books: Nate Silver’s The Signal and the Noise, two books by Nassim Nicholas Taleb: The Black Swan and Fooled by Randomness. Dan Ariely’s book Predictably Irrational. Robert Kaplan’s Revenge of Geography and Daron Acemoglu’s Why Nations Fail. Robert McNamaras In Retrospect and Jim Paul’s What I Learned Losing a Million Dollars. Apparently none of which helped him very much given his self-proclaimed abysmal record making accurate forecasts in identity and access management. For example, he forecast in the mid 2000’s that WS-* would be the predominant federation protocol among other equally inaccurate claims. He totally missed the rise of mobile computing. And even more amazingly, companies paid him his inaccurate advice. Hearing stuff like this makes me nervous about the big bets Gluu has placed on OAuth2, and reminded me that if Gluu is able to invest our scarce resources properly in one of the most dynamic technical markets, we’re probably more lucky than smart.
Most Americans are unaware of the identity card programs that have been undertaken by almost all European governments. The conference featured talks on the efforts of Sweden, Germany, and Belgium. All of these cards can be used to access government services. But many are expanding to B2B and B2C purposes. For example, in Belgium there are beer vending machines that read the birthday off of your national id cards to figure out if you’re old enough to be served. In Japan I video-taped a machine that automatically poured a glass of beer. Its clear… our country is just so far behind, it’s ridiculous.
Given my keen interest for federation, the talk I got the most out of was Rainer Horbe’s ’s talk on federation. Austrians clearly understand the value of federations, and also that these federations are hard to form. So the Austrian Chamber of Commerce formed the Wirtschaftsportalverbund (which believe it or not is an abbreviation for something like the Austrian Identity Federation Authority) which aims to establish B2B and B2C federations the cost of identity management and SSO. This group is creating a framework to help businesses jumpstart federations, including the required technical and governance components.
One of the most interesting conversations I had at the conference was with Haydar Cimen from KPN and Steve Pannifer from Hyperion Consulting regarding Snowden. While a majority of Americans now regard him as a heroic whistle blower, his support in Europe is even higher. In fact, I seem to be the only one in my industry who thinks he needs to answer for his actions. My problem is that if more people follow his precedent, our government and businesses couldn’t operate. If he thinks the moral imperative to uncover this wrong was sufficient to justify his actions, he shouldn’t be hiding in Russia. If he had stayed in the US, I’d support him for standing up for his beliefs. Many people don’t think he would have gotten a fair trial if he had stayed. Or that maybe the government would have water-boarded him, or left him in solitary for years like they did to Manning. Whatever you think of Snowden, it’s clear that our allies view the US as little better than China, are hesitant to travel to the US for fear of being the victim of a big-data analysis snafu, and are resentful that their systems are being hacked in the pursuit of America’s enemies in a covert cyber war for which we apparently have a great talent (and an insane amount of budget).
I was happy to see many old friends, especially from Surfnet and Kinnesnet. I also got a chance to chat with Hans Zandbelt from Ping Identity. Apparently after working all day on helping companies implement federation, he can’t get enough, so he has been moonlighting to write his own OpenID Connect plugin for Apache. It’s much simpler than the one Gluu has undertaken in our crowd-sourcing project. The nice thing about it is that it is standalone. Gluu uses a local process, “oxd”, to handle the OAuth2 messaging. Some people don’t want this additional complexity. We used this approach because it enabled us to leverage our Java libraries for OpenID Connect and UMA, and it would have taken us too long to do all the messaging in C (as we already have Java libraries written). Hans’ plugin supports less features, but its a great example of how you can use a subset of the features if it suits your purpose. More options for developers is great, so I hope Hans has the energy to keep working on it, and to make it available to other developers. If you want to look at the code, its currently here.
Finally, one of the best uses of technology on display in a video from the UK by hipster the “Urban Wizard.” To express his identity he likes to dress up like a wizard when he walks around London. He melted his Oyster card (subway debit card), and attached the chip to his staff. As he walks into the subway, he touches his staff to the turnstiles, and magically, the doors swing open. Apparently the police were not amused, and won’t let him do this anymore. But it’s a reminder that technology is not a one-size fits all affair. People will use things in ways the developers never intended. Who knows what OX will be used for one day… open source and open standards are more embracing of this phenomenon than the metro police
Article Resource:- http://thegluuserver.tumblr.com/post/68143784696/postcard-from-identitynext-2013
Wednesday, 30 October 2013
Gluu Federation Registry Service
There has been a hoopla about what to expect out of the Gluu Federation Registry Service here’s what you get from the Gluu Federation Registry Service:
Support for the design of a multi-party federation that enables autonomous domains to use SAML or OAuth2 for authentication and authorization
Creation of a Sample Participation Agreement—will require review and modification by the federation host.
Creation of initial schema for attributes, authentication, and authorization
Deployment of the Federation Registry application on an IAAS server or a Gluu Server
Customization of the registration process to automate the on-boarding of new application and identity providers into the network
Functional testing of the Federation Registry software for identity provider and application enrollment
Development of a operations guide for Registry Administrators
Training for Registry Administrators who will take over the responsibility of vetting and approving new identity providers and applications into the network.
Annual subscription to support and Monitoring of the Federation Registry instance.
Subscribe to:
Posts (Atom)