For our first Developer Spotlight, we have chosen to shed a light on Kapture’s System Architect – Mr. Rajesh Prasad Gupta. A prominent member of the Kapture team, he brings his expertise and demure into work each day. He has been a part of Kapture for the better of a decade and he delves into DevOps and project handling modules. Below is a detailed account of the Azure AD integration that he worked on with excerpts from the man himself.
What Kapture focuses on is a Single Sign-On protocol to make it simpler for companies to let external vendors and regular employees to log in to their system. This was made possible with a Microsoft Azure Active Directory integration. Azure AD is a cloud-based access management service that is primarily implemented to allow access resources (both external and internal) in and also facilitate sign-ins for employees. The Azure integration is for users in the Microsoft Active Directory with an internal single sign-on function.
Mr. Rajesh says that they provide clients with the option of choosing from two different standards for achieving SSO (single sign-on) – OAuth 2.0 (Open Authorization) and SAML (Security Assertion Markup Language). When asked for a preferred standard, he said, “There is no preference, personally. OAuth 2.0 does not deal with authentication. It is for authorisation of resources. Whereas, SAML is an umbrella standard for exchanging authentication and authorisation between parties, mainly between an identity provider and a service provider. SAML is more secure.”
Usually, when at least one party is an enterprise, SAML is recommended. OAuth is more useful in the case of providing temporary access to resources such as files, pictures or accounts.
The basic functionality of both processes in tandem with Kapture is explained below:
If OAuth 2.0 is elected, the process is pretty straightforward. The cloud-based MS Azure credentials are allotted to each user. Then, Kapture is allowed access to each users Active Directory data for the sign on and sign out sessions.
The SAML protocol first includes creating an SAML entry in the Active Directory. The, Kapture allots a URL to the client to be embedded in their system. Once it is applied and integrated, they pass the response code back to Kapture and a Sign-In option is set up, ready for use.
Regarding the development of said protocol, Mr. Rajesh added, “Earlier, data was synced every 24 hours to include all new users, which has now been reduced to just 2 hours. This means that new employees can use the MS Azure login almost immediately and Kapture collects all data without any delay.”
The primary purpose of having this integration is to log in with Kapture without going through the hassle of an extensive and rigorous authentication protocols. This seamless function fastens the process, since everybody already is assumed to have an active directory login.
A flowchart of how the SAML 2.0 protocol requests and responds for authentication is as follows:
To request user authentication, an
AuthnRequest element is sent to the Azure Active Diectory.
A sample of it looks like this:
<samlp:AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="id6c1c178c166d486687be4aaf5e482730" Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.contoso.com</Issuer> </samlp:AuthnRequest>
Response element includes the result of the authorization request, as given below.
<samlp:Response ID="_a4958bfd-e107-4e67-b06d-0d85ade2e76a" Version="2.0" IssueInstant="2013-03-18T07:38:15.144Z" Destination="https://contoso.com/identity/inboundsso.aspx" InResponseTo="id758d0ef385634593a77bdf7e632984b6" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer> <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <Assertion ID="_bf9c623d-cc20-407a-9a59-c2d0aee84d12" IssueInstant="2013-03-18T07:38:15.144Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> <Issuer>https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer> <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature> <Subject> <NameID>Uz2Pqz1X7pxe4XLWxV9KJQ+n59d573SepSAkuYKSde8=</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData InResponseTo="id758d0ef385634593a77bdf7e632984b6" NotOnOrAfter="2013-03-18T07:43:15.144Z" Recipient="https://contoso.com/identity/inboundsso.aspx" /> </SubjectConfirmation> </Subject> <Conditions NotBefore="2013-03-18T07:38:15.128Z" NotOnOrAfter="2013-03-18T08:48:15.128Z"> <AudienceRestriction> <Audience>https://www.contoso.com</Audience> </AudienceRestriction> </Conditions> <AttributeStatement> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"> <AttributeValue>firstname.lastname@example.org</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier"> <AttributeValue>3F2504E0-4F89-11D3-9A0C-0305E82C3301</AttributeValue> </Attribute> ... </AttributeStatement> <AuthnStatement AuthnInstant="2013-03-18T07:33:56.000Z" SessionIndex="_bf9c623d-cc20-407a-9a59-c2d0aee84d12"> <AuthnContext> <AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion> </samlp:Response>