OpenID Connect and UMA Apache HTTPD Plugins Are On the Way!

The Gluu Management was upbeat and thanked all the supporters of their CrowdTilt Campaign $7,975 that had been crowd-funded to enable the development of Open Source OAuth2 plugins for the Apache HTTPD server!

Support that flowed in from various sources and quarters has been given due credit by the management of Gluu

1) Andrew Hughs for convincing me, despite my original skepticism, that we should try to crowd fund the plugin. Not only did we raise $8,075, we generated a lot of awareness, and built the community of OX supporters in the process. Andrew was a key catalyst in making this happen!

2) Eve Maler (and the UMA team) for writing UMA. OX’s vision for open source access management for organizations would not be possible without UMA. For Eve and her UMA collaborators, it has been a marathon effort for many years, and its a miracle that people would be as committed to the effort! Thank you for your hard work which makes something like a plugin even possible!

3) Kantara One of the key catalysts in this campaign, we should all thank Joni Brennan for her work on UMA and other important standards efforts. A neutral partner to help the participants of the ecosystem is essential.

4) OpenID Connect Working Group: For also being so damn persistent… few people realize how many issues need to be resolved to get a large and important standard written. Without their work, we would have nothing to implement.

5) 30+ passionate identity evangelists. Individuals were the first contributors to the campaign, and funded 30%, which is a key sign of support. Without this, I don’t think the corporate sponsors would have joined. This group did double what I expected… and many people even upped their contribution when it looked like we were not going to make it! Thank you everyone!

6) CrowdTilt I have been a fan of CrowdTilt since it launched a few years back. Behind the scenes, they are making sure it all works. Thank you all for your dedication!

7) Falcon Systems Consulting of Japan. Falcon was the first and largest corporate sponsor. I was short $5,000 on our campaign. By offering to cover half, it made the raising the final third seem possible. After closing the loop with potential corporate sponsors, we tilted! I went into work not thinking the campaign had failed, and I left work, we had commitments to get the campaign tilted. Thank you to Masamichi Takahashi for supporting open source and open standards and leading the way in Japan!

8) Symas. Thank you to Marty Heyman and Shawn McKinney for contributing to the campaign, for their hard work developing an open source identity stack, and for inviting me to the Java One IAM Panel

9) ForgeRock. We’re really happy to collaborate with ForgeRock. Without other implementers of OpenID Connect and UMA, Gluu’s platform would be just as proprietary as the monolithic IAM solutions. ForgeRock’s financial support is really appreciated, but their future participation in open standard interops will pay even bigger dividends for the Internet. Special thank you to Lasse Andresen and Allen Foster!

10) All you guys Thank you for to everyone else out there who helped us by RE-TWEETing and helping to get the word out. We had more than 3000 twitter clicks on our campaign. Without your help, we couldn’t have found all the poeple out there who want

Gigaom

Cable operator Charter (S CHTR) is looking to bring the cloud to its customers’ cable boxes, regardless of when those devices were made: Charter CEO Tom Rutledge said during the company’s earnings call Thursday that his company intends to roll out a new, cloud-based UI to all of its set-top boxes next year. Rutledge added that initial tests in Fort Worth, Texas have been promising, and that Charter will expand these tests to additional markets later this year. Charter announced 29,000 video subscriber losses Thursday, down from 55,000 a year ago.

Charter’s new cloud UI.

Charter is using cloud virtualization technology from ActiveVideo to revamp the user interfaces of its cable boxes without actually having to upgrade the hardware. This is being accomplished by hosting the UI in the cloud, where it is rendered into a video stream that can be played back even with legacy pay TV hardware. The…

View original post 274 more words

How to benchmark OX for a large scale deployment

OX was designed from the ground up to support clustered deployments. The application is stateless: no HTTP sessions are ever used. Even in a two-step authentication, it is not assumed that step one and step two will be handled by the same server. For this reason, OX can be clustered with any load balancer algorithm, for example, round-robin or failover.

Authentication services are only as robust and performant as their underlying persistence mechanisms.

OX uses the LDAPv3 interface for persistence of configuration, user data, and session information. The best two open source LDAP servers are OpenDJ and OpenLDAP. The best non-open source LDAP server is UnboundID. UnboundID also offers an LDAP proxy. To maximize the performance of an LDAP server, the entire dataset must be stored in memory–including the data and the indexes. Even for write performance, keeping the dataset in memory (and proper indexing of course), is necessary.

For a large scale deployment, where the entire data set cannot be stored in one LDAP server’s memory, the best strategy is to split the data up in two servers. For example, store users with last name A-M in one set of servers, and last name N-Z in another set of servers. In this case, the UnboundID proxy can use a cross-sever “global” index to route requests to the respective server that holds the entry.

OpenID Connect and UMA offer many endpoints to benchmark.

The OpenID Connect endpoints are :

authorization_endpoint
token_endpoint
userinfo_endpoint
clientinfo_endpoint
check_session_iframe
end_session_endpoint
registration_endpoint
validate_token_endpoint

The UMA endpoints are :

dynamic_client_endpoint
token_endpoint
user_endpoint
introspection_endpoint
resource_set_registration_endpoint
permission_registration_endpoint
rpt_endpoint
authorization_request_endpoint
scope_endpoint

Furthermore, oxTrust provides SCIM endpoints, which can be used for identity and credential management, and provides additional interactive business logic.

One important consideration for scalability is logout. For example, millions of clients polling repeatedly to make sure their session is still valid is a waste of valuable server resources. OpenID Connect defines a javascript session management mechanism. In this schema, javascript is inserted into each web page, and this polls a local browser flag to find out if another tab has logged out.

The approach can be problematic if the tab is not present when the logout occurs (i.e. the application may not be notified of the logout). If this mechanism is deemed insufficient for the requirements, an alternate logout strategy will need to be devised. Normally this may include using a callback to the registered back-end applications either in serial or parallel.

Benchmarking is an interactive process where the results of one iteration are used to optimize the starting configuration of the next iteration. The components of the infrastructure need to be tested individually. It is then important that the tests try to replicate the expected usage patterns.

For the OX APIs, Gluu can assist in the creation of test data, generation of the load, monitoring of the JVM for memory and connection leaks, and reporting on the resulting throughput.

For LDAP, the SLAMD tool is available. This tool provides load generation, measurement, system performance, and throughput reporting. The tool can be customized to include the collection of custom metrics to enable correlation of performance to OX API usage. Another consideration is to run long lived tests to make sure that replication data does not bloat entry size and negatively effect performance.

To CAS or not to CAS

 

Is CAS the hidden gem of authentication API’s or should it be end-of-life? Unequivocally, Gluu’s position is the latter–CAS filled a needed gap at the time, but now application developers should be discouraged from expanding the use of CAS. Here is why…

Background

Developed at Yale in the early 2000’s, CAS is now hosted by Jasig, a consortium that fosters open source software projects for higher education. CAS version 2.0 was finalized in 2005 about two years before the iPhone was introduced. CAS is known for its developer friendly (easy) client API. There are lots of CAS libraries for different programming languages, and many plugins are available for other open source projects. Its also supported by some vendors. For even more background, Wikipedia gives an informative overview of CAS.

Why not use CAS?

There are a few reasons you should steer clear.

CAS does not support OAuth2, and it probably never will. Faceook, Google, and Yahoo use OAuth2 for authentication, which represents about 85% of consumer authentications according to Janrain (provider of a widely used uber-authentication-api). Large consumer IDPs that are using OAuth2 are likely to quickly adopt the “OpenID Connect” profile of OAuth2, which will incentivize a staggering number of websites to follow. This will overshadow all previous web SSO/federation standards like CAS, old versions of OpenID, old versions of OAuth, and even SAML.

If you compare CAS and OpenID Connect, you’ll see not only does CAS have less features for authentication, but it does not support many of the endpoints defined by Connect: dynamic client registration, discovery, user claims, client claims. So its not just a matter of a different protocol for authentication, but a lot of missing functionality.

Even SAML support is weak. Many institutions that want both CAS and idp SAML use a “Login Handler” in the Shibboleth SAML IDP software to validate the username/password creds against the CAS server. In this way, the person gets both a CAS token and a SAML token, and has SSO with both kinds of apps.

In CAS, its not that easy to implement new types of multi-step authentication. Most deployments of CAS are for username/password authentication.

While its easy for mobile applications to use the CAS API to validate credentials, the protocol does not lend itself to more complex authorization scenarios where the backend services have different levels of permissions.

Conclusion

Like the little ant, OpenID Connect has high hopes. Where possible, use it. Make sure developers understand the roadmap for your organization: your domain, like all the other domains on the Internet, will adopt OpenID Connect. Use SAML to fill in the gaps until all the OpenID Connect libraries and web server plugins are available. SAML is going to be around much longer than CAS, so its a better bridge solution. Use CAS only as a last resort. You should require products and software that supports the identity integration method that align with your roadmap. Be flexible…using CAS is better than the app storing its own passwords. However, realize that this application will probably never support the two factor authentication services available in OAuth2 and SAML. There are many “good” legacy SSO protocols, don’t forget Siteminder in the Enterprise world… however, if you’re faced with the situation… try NOT TO CAS.

Five Interceptions of the OX OP

Gluu has designed OX to be very flexible. OX admins can use Jython scripts to customize behavior.

Jython was chosen because an interpreted language facilitates dynamic creation of business logic, and makes it easier to distribute this logic to a cluster of OX servers. Another advantage of Jython was that developers can use either Java or Python classes. Combined with the option of calling web services from Python or Java, this enables OX to support any crazy requirement. Domains can use OX “interception” scripts to code their own business logic in five areas:

Authentication: Implement adaptive authentication to identify people in one or more steps.

Authorization: Express your policies in Python or Java, or call and external entitlements management system, like XACML or SiteMinder.

Attribute Transformation: Create new attributes, change attribute names, or change the value of existing attributes.

Logout: Make sure you logout of any backend services, such as an external IDP or porotal, or SSO environment.

ID Generation: People don’t see their internal id, but domains may want to use one convention or another to provide a “primary key” value to identify an entity (person, client, etc.) UUID’s are the most common, but also used is IPv6 addresses, DNS style names, or custom schemes.

Authentication Script

Interface:

public interface ExternalAuthenticatorType {

public boolean init(Map configurationAttributes);

public boolean authenticate(Map configurationAttributes, Map requestParameters, int step);

public boolean prepareForStep(Map configurationAttributes, Map requestParameters, int step);

public int getCountAuthenticationSteps(Map configurationAttributes);

public String getPageForStep(Map configurationAttributes, int step);

public List getExtraParametersForStep(Map configurationAttributes, int step);

}
Sample Script

from org.jboss.seam.security import Identity
from org.xdi.oxauth.service.python.interfaces import ExternalAuthenticatorType
from org.xdi.oxauth.service import UserService
from org.xdi.util import StringHelper

import java

class ExternalAuthenticator(ExternalAuthenticatorType):
def __init__(self, currentTimeMillis):
self.currentTimeMillis = currentTimeMillis

def init(self, configurationAttributes):
return True

def authenticate(self, configurationAttributes, requestParameters, step):
if (step == 1):
print “Basic authenticate for step 1”

credentials = Identity.instance().getCredentials()
user_name = credentials.getUsername()
user_password = credentials.getPassword()

logged_in = False
if (StringHelper.isNotEmptyString(user_name) and StringHelper.isNotEmptyString(user_password)):
userService = UserService.instance()
logged_in = userService.authenticate(user_name, user_password)

if (not logged_in):
return False
# Commented out becuase we do the same in AuthenticationService.authenticate method
#
# user = userService.getUser(user_name)
# if (user == None):
# print “Basic authenticate for step 1. Failed to find user in local LDAP”
# return False
#
# # Store user to allow use this module for web services
# credentials.setUser(user);

return True
else:
return False

def prepareForStep(self, configurationAttributes, requestParameters, step):
if (step == 1):
print “Basic prepare for Step 1”
return True
else:
return False

def getExtraParametersForStep(self, configurationAttributes, step):
return None

def getCountAuthenticationSteps(self, configurationAttributes):
return 1

def getPageForStep(self, configurationAttributes, step):
return “”
Attribute Transformation Script
Interfaces:

public interface EntryInterceptorType {

public boolean updateAttributes(GluuCustomPerson person);

}
Sample Attribute Transformation Script

# Import of Java classes
from org.gluu.site.ldap.cache.service.intercept.interfaces import EntryInterceptorType
from org.gluu.site.util import StringHelper
from org.gluu.site.model import GluuCustomPerson
from org.gluu.site.model import GluuCustomAttribute

import java

class EntryInterceptor(EntryInterceptorType):
def __init__(self, currentTimeMillis):
self.currentTimeMillis = currentTimeMillis

def updateAttributes(self, person):

# Assign the current entry’s attributes to an array
attributes = person.getCustomAttributes()

# Create and set the attribute eduPersonPrincipalName
uidValue = person.getAttribute(‘uid’)
attrEPPN = GluuCustomAttribute(‘edupersonprincipalname’, uidValue + ‘@example.edu’)
attributes.add(attrEPPN)

# Loop through each attribute in the current entry
for attribute in attributes:
attrName = attribute.getName()

# The mapping in the Cache Refresh configuration page set employeeType to
# eduPersonScopedAffiliation(EPSA). This means that EPSA currently has an
# integer value instead of the value expected by Educause. It needs to be
# set to the correct value.
if (“edupersonscopedaffiliation” == StringHelper.toLowerCase(attrName)):
attrValue = attribute.getValue()
newEPSAValue = []

if (attrValue==1):
newEPSAValue.append(‘student@example.edu’)
elif (attrValue==2):
newEPSAValue.append(‘faculty@example.edu’)
elif (attrValue==3):
newEPSAValue.append(‘student@example.edu’)
newEPSAValue.append(‘faculty@example.edu’)
elif (attrValue==4):
newEPSAValue.append(‘staff@example.edu’)
elif (attrValue==5):
newEPSAValue.append(‘staff@example.edu’)
newEPSAValue.append(‘faculty@example.edu’)

# Remove current attribute which is EPSA with an integer value
attributes.remove(attribute)
epsa = GluuAttribute(‘eduPersonScopedAffiliation’, newEPSAValue)
attributes.add(epsa)
return True
Authorization Script
Interfaces:

public interface IPolicyExternalAuthorization {
public boolean authorize(AuthorizationContext p_authorizationContext);
}

public interface IAuthorizationContext {
String getClientClaim(String claimName);
String getUserClaim(String claimName);
String getUserClaimByLdapName(String ldapName);
Integer getAuthLevel();
String getAuthMode();
String getIpAddress();
boolean isInNetwork(String cidrNotation);
RequesterPermissionToken getRPT();
ResourceSetPermission getPermission();
AuthorizationGrant getGrant(); // here return unmodifiable version of grant, e.g. to avoid new token creation
HttpServletRequest getHttpRequest();
}
Python sample authorization script (authorize only if user location claim equals to Austin)

from org.xdi.oxauth.service.uma.authorization import IPolicyExternalAuthorization
from org.xdi.util import StringHelper

class PythonExternalAuthorization(IPolicyExternalAuthorization):

def authorize(self, authorizationContext):

print “authorizing…”

if StringHelper.equalsIgnoreCase(authorizationContext.getUserClaim(“locality”), “Austin”):
print “authorized”
return True

return False

Logout
Interface:

public interface CustomLogoutScript{

/**
* Provides an interception to insert domain specific logic when a person logs out,
* such as logout to backend IDPs.
*
* @param p_idType id type : use to specify entity type, i.e. person, client
* @return int result code
*/
public String logout(String message);
}
Sample Script:

import myIDP

class ExampleDomainLogout(CustomLogoutScript):
def logout(self, message):
print “Executing %s” % message
try:
myIDP.logout()
except Exception, err:
print Exception, err
return 1
return 0
GenerateID
Interface:

public interface IdGenerator {

/**
* Generates id.
*
* @param p_idType id type : use to specify entity type, i.e. person, client
* @param p_idPrefix id prefix : If you want to prefix all ids, use this, otherwise pass “”
* @return generated id as string
*/
public String generateId(String p_idType, String p_idPrefix);
}
Sample Script:

import uuid

class ExampleDomainUniqueIdPolicyClass(IdGenerator):
def generateId(self, entityType, prefix):
print “Generating %s ID for prefix %s” % entityType, prefix
# make a UUID using an MD5 hash of a namespace UUID and a name
id = uuid.uuid3(uuid.NAMESPACE_DNS, ‘example.co’)
return “%s%s” % (prefix, id)

Article Source – http://www.gluu.org/blog/five-interceptions-of-the-ox-op/