nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ipse for single sign on - background details

bcmp

How does implementing ipse helps to implement single sign on from other web applications. Much appreciated for sharing details of it.

Find more posts tagged with

Comments

Clement Wong

Overview 
 
 Implementing a single sign-on mechanism in the BIRT iHub Information Console is made possible by the Information Console Security Extension or ICSE. Previously, this was known as the iPortal Security Extension (IPSE), so you may hear it referred to as the IPSE. The ICSe is a Java based class which extends the iPortalSecurityAdapter class, and is written by the integrator or developer responsible for implementing BIRT iHub. This Java class is then called by Information Console when authentication is required. 
 There are several methods that Information Console will require to be implemented in order for the ICSE to work properly. Here is a list of those methods: public boolean authenticate(HttpServletRequest) 
 public String getUserName() 
 public String getPassword() 
 public String getVolume() 
 public byte[] getExtendedCredentials() 
 public boolean isEnterprise() 
 public String getUserHomeFolder() 
 public String getRepositoryType() 
 public String getServerUrl() 
 public String getVolumeProfile() 
 So essentially, each time authentication is required Information Console will first call the authenticate() method passing the HttpServletRequest object. It is up to the developer to decide how they would like to obtain the user credentials from the request. If the authenticate() method finds the appropriate information, it should return true, signaling Information Console that the user credentials were as expected in the request. 
 
 Information Console then subsequently calls the remaining methods, such as getUserName() and getPassword() in order to obtain the user's information. This information is then used in the subsequent IDAPI calls to authenticate the user to the iHub itself. In essence, Information Console is then impersonating that user on all calls to the iHub on their behalf. 

Example
 
 In the example ICSE, the authenticate() implementation has two methods to obtain the username and password information. The volume name and volume profile are hard-coded in the example, but can be dynamically set to the corresponding volume and volume profile values. 
 The first method to obtain the username and password information is cookie-based, while the secondary method is based on two session attributes. The username cookie is named "actUserName" and the password cookie is named "actPassword". If the ICSE finds that these cookies exist, it will set the sUserName and sPassword string variables to the cookie values.
 
 The ICSE will then set the two corresponding session attributes for the username and password when found. Subsequently, it will also check to see if the session attributes exist if the cookie values are not found. We will ensure that calls to Information Console following the initial call will succeed for the user's session once they have provided the correct login information. If either the cookies were found, or the session attributes, the authenticate() method will return true, else it will return false. 
Here is the code for the authenticate() method:
<pre class="_prettyXprint">
public boolean authenticate(HttpServletRequest httpservletrequest)
 {
 //Make sure return flag is false every time by default
 //and that sUserName and sPassword are null for any authenticate calls
 retFlag = false;
 sUserName = null;
 sPassword = null;

 //Create cookies[] array and loop through it
 //for the "actUserName" and "actPassword" cookie values
 //then set the member variables returned from getUserName()
 //and getPassword() based on what is found

 try {
 Cookie[] cookies;
 cookies = httpservletrequest.getCookies();
 int x;
 for(x=0;x<=cookies.length;x++){
 if(cookies[x].getName().equalsIgnoreCase("actUserName")){
 sUserName = cookies[x].getValue();
 retFlag = true;
 } else if(cookies[x].getName().equalsIgnoreCase("actPassword")){
 sPassword = cookies[x].getValue();
 retFlag = true;
 }
 }

 if(sUserName != null && sPassword != null){
 retFlag = true;
 }

 //Create session handle.
 HttpSession session = httpservletrequest.getSession();

 //Test for cookie information populated to variables and set return flag.
 //If found, set the session attributes with corresponding values.
 if(sUserName != null && sPassword != null){
 session.setAttribute("actuUserName", sUserName);
 session.setAttribute("actuPassword", sPassword);
 retFlag = true;
 }

 //Get session handle and look for our previous entry
 //if we didn't find it in new cookie values and set return flag.
 if(retFlag = false){
 if(session.getAttribute("actuUserName") != null){
 sUserName = session.getAttribute("actuUserName").toString();
 sPassword = session.getAttribute("actuPassword").toString();
 retFlag = true;
 }
 }
 } catch (Exception e) {
 e.printStackTrace();
 }

 //Return true if either the cookies or the session attributes were found.
 return retFlag;

 }
</pre>
 It is also important to note that the code above simply populates the member variables, while calls from Information Console to retrieve the username and password simply return those variables. As shown below:
<pre class="_prettyXprint">
 public String getUserName()
 {
 return sUserName;
 }

 public String getPassword()
 {
 return sPassword;
 }</pre>
 
 In summary, the ICSE only attempts to populate values, while the iHub itself carries out the actual authentication and validation of the values found by the ICSE. It is up to the iHub administrator to create the usernames and set the correct passwords, or via an RSSE or Report Server Security Extension to retrieve them. (RSSE info @ <a data-ipb='nomediaparse' href='http://developer.actuate.com/be/documentation/ihub31-dev/AIG-main/index.html#page/aig/UsingJavaRSSE.html#)'>http://developer.actuate.com/be/documentation/ihub31-dev/AIG-main/index.html#page/aig/UsingJavaRSSE.html#)</a> 

 
 
 
For more information in the documentation, please read more:
<a data-ipb='nomediaparse' href='http://developer.actuate.com/be/documentation/ihub31-dev/AIG-main/index.html#page/aig/Using-IC-Security.16.07.html#'>http://developer.actuate.com/be/documentation/ihub31-dev/AIG-main/index.html#page/aig/Using-IC-Security.16.07.html#</a>
 
<a data-ipb='nomediaparse' href='http://developer.actuate.com/be/documentation/ihub31-dev/AIG-main/index.html#page/aig/Using-IC-Security.16.09.html#'>http://developer.actuate.com/be/documentation/ihub31-dev/AIG-main/index.html#page/aig/Using-IC-Security.16.09.html#</a>
 
 
An example of a non-cookie based IPSE:
<a data-ipb='nomediaparse' href='https://github.com/ActuateBIRT/ServerIntegrationIPSEExample'>https://github.com/ActuateBIRT/ServerIntegrationIPSEExample</a>

bcmp

If only one user account is used like administrator, the username can be set as administrator in the authenticate method along with the password and return true. Will it work? 
By the way, thanks! for the write up. Great!

Clement Wong

That would be a non-secure IPSE, and only useful for demo purposes.
 
Here is what a hard-coded IPSE would look like:
<pre class="_prettyXprint _lang-">
package com.actuate.sample.sso;

import javax.servlet.http.HttpServletRequest;

import com.actuate.iportal.security.iPortalSecurityAdapter;

public class SampleIPSE extends iPortalSecurityAdapter {

String username = "administrator";
String password = "";
String volume = "Default Volume";
String volumeProfile = "Default Volume";

public boolean authenticate(HttpServletRequest httpServletRequest) {
return true;
}

public String getUserName() {
return username;
}

public String getPassword() {
return password;
}

public String getVolume() {
return volume;
}

public String getVolumeProfile() {
return volumeProfile;
}
}
</pre>

bcmp

Just few queries on top of it.
 
1) Once the user log out from the external application, are there ways to clear the session variables set in custom ICSE implementation class.
2) Once ICSE implementation is done, for example, the login details for ICSE are stored in cookies from the external app. How will login mechanism to iportal (default web portal) works where ICSE implementation looks for cookies or session variables for user credentials.
 
 
Really appreciated, for the time and effort.