Showing posts with label SAML. Show all posts

Wednesday, April 12, 2017

Shibboleth Idp with External Authn Configuration

Shibboleth Idp comes with by default various flows like UsernamePassword, Mfa, X509, Kerberos, Spengo and various others flow but today I am going to discuss in details about one more flow which is also provided by Shibboleth Idp itself i.e External Flow

Use case:

Shibboleth Idp supports external Authn flow using which specific requirement can be fulfilled like your authentication database resides at some other location or some other servlet will do the authentication on the Idp’s behalf like authentication should be done at Facebook or Google side. All such scenario can be easily handled using External Authn flow.

Shibboleth team has already created document for the same which you can read it over here. I am writing this document to explain it in more details with example.

There are few predefined steps that we need to follow to add new custom flow in Shibboleth Idp as per Shibboleth guidelines. Let’s assume we have to create new flow named “Authn/Custom” in Shibboleth Idp.

Here are the steps:

Copy opt\shibboleth-idp\conf\authn\ external-authn-config.xml and change it to custom-authn-config.xml and keep it under the same directory i.e. “opt\shibboleth-idp\conf\authn”.
Replace all ‘External’ with ‘Custom’ in custom-authn-config.xml file like

<bean id="shibboleth.authn.External.externalAuthnPath" class="java.lang.String"

c:_0="contextRelative:Authn/External" />

<bean id="shibboleth.authn.Custom.externalAuthnPath" class="java.lang.String"

c:_0="contextRelative:Authn/Custom" />

Copy files from system to flow folder:

cp system/flows/authn/external-authn-flow.xml flows/authn/Custom/Custom-flow.xml

cp system/flows/authn/external-authn-beans.xml flows/authn/Custom/Custom-beans.xml

Note: Make sure the name of the folder should be same as flow name. over here it is Custom and Replace all ‘External’ with ‘Custom’ and edits the correct path too in both files.

Create a java project and create new Servlet CustomAuthnFlowServlet”. Servlet should contain final String key= ExternalAuthentication.startExternalAuthentication(httpRequest) and ExternalAuthentication.finishExternalAuthentication(key, httpRequest, httpResponse) and the authentication logic should be added between this statement and If you are doing any redirect then make sure you should persist the key as startExternalAuthentication & finishExternalAuthentication require the same key.

One more point principal should be set as httpRequest.setAttribute(ExternalAuthentication.PRINCIPAL_NAME_KEY, username) if you want to retrieve at Shibboleth SP side and in case of error mapped it with AUTHENTICATION_ERROR_KEY. httpRequest.setAttribute(ExternalAuthentication.AUTHENTICATION_ERROR_KEY, AUTHN_EXCEPTION);

Add new Servlet mapping to web.xml file of Shibboleth Idp.

Add your custom exception that we have created in our Servlet in opt\shibboleth-idp\conf\authn\authn-events-flow.xml.

Add below snippet to opt\shibboleth-idp\conf\errors.xml

<entry key="CustomException" value-ref="shibboleth.SAML2Status.AuthnFailed" />

<entry key="AnotherException" value-ref="shibboleth.SAML2Status.AuthnFailed" />

Note: Map your Exception to correct value-ref as incase of error Idp will send this error Response to Shibboleth SP.

Set idp.authn.flows as Custom (idp.authn.flows=Custom)
We can retrieve Principal at Shibboleth IdP side by adding below snipped in attribute-resolver.xml.

We are done here. Restart Shibboleth and hit target URL and you will see the SSO happening using your custom flow. Please feel free to comment or mail me for any queries.

Happy Coding!!!

Wednesday, February 22, 2017

OAuth vs SSO: Which One Should I Use?

Currently, I am working on one project which provided me a lot of opportunities to learn about OAuth 2.0 and SAML and better understanding on which one to choose for SSO strategy.
I am choosing this topic because most of the people get confused between these two. While they have some similarities but they are very different too and to put it one line. I would say “OAuth is not Single Sign-On”

What is the difference between OAuth 2.0 and SSO?

OAuth (Open Authorization) is a standard for authorization of resources. It does not deal with authentication. It allows secure authorization in a simple and standard method from web, mobile and desktop applications.

If you try to log into Stack Overflow using Facebook, you’ll be redirected to Facebook’s website and will see something like the following:

Once authenticated with Facebook, it will ask for Stack Overflow’s permission to access your resources like your name, Email id, Profile picture and so on. This is an authorization request like what Stack Overflow can do and what cannot do?

SAML: Security Assertion Markup Language is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. It is an umbrella standard that encompasses profiles, bindings and constructs to achieve Single Sign-On (SSO), Federation and Identity Management.

SSO is an authentication/authorization flow through which a user can log into multiple services using the same credentials.
For instance, at your company where we have various applications like leave application, lunch application, career application and so on and we can configure all these applications to one Active Directory for authentication. Another example can be Atlassian account where you once logged in can use their other applications like Bamboo, JIRA, Confluence and so on.

Both examples represent SSO.

One of the main benefits to using SSO is that your users have only a single account and password to remember which gets them into all of their services.

Conclusion: When Should I Use Which?

If your use case requires a single account to log into many applications, then go with SSO like your internal company applications.
If your use case involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc.), then use OAuth.
If your use case requires a centralized identity source, then use SSO.
If your case requires to have accounts on many different services, and selectively grant access to various services, use OAuth

Saturday, October 3, 2015

Configure Shibboleth Idp to achieve Single Sign-on with Zendesk

1. Introduction

Shibboleth is standards-based, open source middleware software which provides web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.
Shibboleth Identity Provider supports the SAML2 specification and is therefore ideal for use with Zendesk. This document will describe the steps required to configure Shibboleth 2.0 Identity Provider to achieve single sign-on with Zendesk.

2. Install Shibboleth IdP

The V2 Shibboleth Identity Provider is a standard Java web application based on the Servlet 2.4 specification and should run for the most part in any compatible servlet container. For this setup, I am going to use Apache Tomcat 7.

Install and configure Apache tomcat 7
Download the Shibboleth Identity Provider (V2.4.4) software package.
Unzip the archive and uncomment <security-constraint>, <login-config> tag from ${shibboleth-identityprovider-2.4.4}\src\main\webapp\WEB-INF\web.xml file.

Run install.bat script. The installation directory given during installation will be known as IDP_HOME throughout this document.

Add https port in all URLs present in '${IDP_HOME}\metadata\idp-metadata.xml' file i.e change all 'https://idp.waheedtechblog.com/idp/shibboleth' to 'https://idp.waheedtechblog.com:8443/idp/shibboleth'.

Skip this step if you have added 'idp.xml' file under '${tomcat}\conf\Catalina\localhost' directory as mentioned in step#1 or else copy '${IDP_HOME}\war\Idp.war' file to '${tomcat}\webapps' directory.

Start tomcat and verify it by accessing the URL: https://<HOSTNAME>:<PORT>/idp/profile/Status. If everything is working correctly, It will display a “ok” page.

3. Configuring Zendesk

Add SAML SSO URL as 'https://idp.waheedtechblog.com:8443/idp/profile/SAML2/Redirect/SSO'. You can find this URL in your '${IDP_HOME}\metadata\idp-metadata.xml' file as HTTP-Redirect URL.
Certificate fingerprint: Double click on '${IDP_HOME}\credentials\idp.crt' file and copy 'thumbprint' value from 'Details' tab. Don't forget to remove the spaces.
Remote Logout URL and IP Ranges are optional. Save it.

4. Configuring Shibboleth Idp

To support SSO, We need to modify many files of IdP.

4.1 Enable logging

Before configuring anything, we should enable LOG at level DEBUG so that we can easily find out the issue. The Identity Provider uses the Logback logging system and logging configuration is located at $IDP_HOME/conf/logging.xml.

Change logger and root level as DEBUG

<logger name="edu.internet2.middleware.shibboleth" level="DEBUG”>
<root level="DEBUG">
<appender-ref ref="IDP_PROCESS"/>
</root>

The file changes will be reflected with in 10 minutes without restarting the IdP and check idp-process.log file for any issue.

4.2 Configure Username/Password Authentication

Authentication handler supports authenticating users with a username (netid) and password.
Uncomment username/password login handler in ${IDP_HOME}/conf/handler.xml file

<ph:LoginHandler xsi:type="ph:UsernamePassword"
jaasConfigurationLocation="file://C:\idpV2.4.4/conf/login.config">
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>

and Comment RemoteUser login handler

Note: Sometimes Idp is not able to find out the login.conf file as mentioned in Username\password login handler. In such cases add one extra '/' in the file path i.e. jaasConfigurationLocation="file:///C:\idpV2.4.4\conf\login.config"

4.3. Add LDAP Login Module Specification

Add Ldap configuration for Authentication to ${IDP_HOME}/conf/login.conf file.

Uncomment and modified LdapLoginModule as per your local environment

edu.vt.middleware.ldap.jaas.LdapLoginModule required

ldapUrl="ldap://localhost:389"

base="dc=altisource,dc=com"

serviceUser="cn=Directory Manager"

serviceCredential="root123"

ssl="false"

subtreeSearch="true"

userFilter="uid={0}";

Where

ldapUrl: url of the ldap where it is running

base: location where you have actually stored username/password (Base DN)

serviceUser: Administrative users using which you connect to Ldap

serviceCredential: Password of the ldap

This is how my Ldap Connection looks like

4.4 Add Zendesk metadata to IdP

The Shibboleth IdP must know some basic information about the Zendesk relying party, which is defined in SAML metadata. Create new IDP_HOME/metadata/zendesk-metadata.xml file with the following contents. There is much more information that could be added here, but this is the minimum required to get things working and replace YOURDOMAIN with the domain you have setup in Zendesk.

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
validUntil="2015-10-03T12:10:16Z"
cacheDuration="PT1444306216S"
entityID="YOURDOMAIN.zendesk.com">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://YOURDOMAIN.zendesk.com/access/saml"
index="1" />
</md:SPSSODescriptor>
</md:EntityDescriptor>

4.5 Configure Relying Party (relying-party.xml)

Instruct Shibboleth how to behave when talking to Zendesk by defining a new RelyingParty element in ${IDP_HOME}/conf/relying-party.xml. The following snippet should be added just after the DefaultRelyingParty element. Change the id and provider value as per your configuration.

<rp:RelyingParty id="https://YOURDOMAIN.zendesk.com"
provider="https://idp.waheedtechblogsso.com:8443/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential">
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" signResponses="never" />
</rp:RelyingParty>

Add the following snippet to configure new metadata (zendesk-metadata.xml) file you have created earlier.

<metadata:MetadataProvider id="IdPSP" xsi:type="metadata:FilesystemMetadataProvider"
metadataFile="c:\\idpV2.4.4\\metadata\\zendesk-metadata.xml" >
</metadata:MetadataProvider>

Add PORT to all URL i.e. change https://idp.waheedtechblog.com/idp/shibboleth to https://idp.waheedtechblog.com:8443/idp/shibboleth in relying-party.xml file

Change encryptAssertions="conditional" to encryptAssertions="never " in 'SAML2SSOProfile'

<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="never" signAssertions="always"
encryptAssertions="never" encryptNameIds="never"
includeConditionsNotBefore="true"/>

4.6 Configure Attribute Resolver (attribute-resolver.xml)

Zendesk expects the email of the user logging in to be passed as the SAML Name Identifier. Shibboleth’s attribute resolver must be configured to make this data available by modifying ${IDP_HOME}/conf/attribute-resolver.xml.

Uncomment and modify Ldap data connector

<resolver:DataConnector id="openDJ" xsi:type="dc:LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://localhost:389"
baseDN="dc=domain, dc=com"
principal="cn=Directory Manager"
principalCredential="root123">
<dc:FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</dc:FilterTemplate>
<ReturnAttributes>mail cn</ReturnAttributes>
<LDAPProperty name="java.naming.ldap.attributes.binary" value="objectSid"/>
<LDAPProperty name="java.naming.referral" value="follow"/>
</resolver:DataConnector>

and then add the following attribute definition that was used to authenticate to the IdP.

<resolver:AttributeDefinition xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="userEmailId" sourceAttributeID="mail">
<resolver:Dependency ref="openDJ" />
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</resolver:AttributeDefinition>

<resolver:AttributeDefinition xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="common_name" sourceAttributeID="cn">
<resolver:Dependency ref="openDJ" />
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="common_name" />
</resolver:AttributeDefinition>

4.7 Configure Attribute Filter (attribute-filter.xml )

Finally, configure the Shibboleth attribute filtering engine to release the principal attribute (encoded as a NameID) to Zendesk. Add the following XML snippet to ${IDP_HOME}/conf/attribute-filter.xml alongside the existing policy elements.

<afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
<afp:PolicyRequirementRule xsi:type="basic:ANY"/>
<afp:AttributeRule attributeID="userEmailId">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>

<afp:AttributeRule attributeID="common_name">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
</afp:AttributeFilterPolicy>

5. Verification

If everything goes well, our Shibboleth Idp should authenticate users to zendesk application.
Let's access zendesk domain: https://waheedtechblogsso.zendesk.com

It will redirect to Shibboleth Idp page for user credential

Once you entered the credential, it will redirect back to zendesk home page. (Just make sure you have the same credential in LDAP that you have used in zendesk to register it.)

Congratulation ...!!!

Tech Trek: A Software Engineer's Guide to Code and Beyond