SAML SSO with Shibboleth

Original Source – SAML SSO with Shibboleth

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/