Showing posts with label isam. Show all posts
Showing posts with label isam. Show all posts

Monday, 23 May 2016

Google Authentication to ISAM/Webseal.

Google Authentication to ISAM/Webseal.

Recently, i was asked if i can implement Social Login to an existing ISAM Webseal.
I heard these words "Social Login" before but never cared to explore on what it was, So the requirement was in most of the websites there is an option called login with Facebook/Google/LinkedIn/Twiiter and similarly can something similar be used in ISAM as well, At first i was a little scared of it, but the concept was very interesting and on further exploring online it felt "Man This is Not so Hard!".

The basic idea was to use these social websites Login and retreive the user data which can be further veified in ISAM LDAP and create a session for the User in ISAM.
On Further exploring i decided on not to use any API calls of these social websites because using API calls would require their respective API Jars, this was something which i really dont want to Use and being an IAM guy i wanted to explore the functionality of OAUTH/OPENID/REST Procedure for this.
Hearing OAUTH/OPENID/REST words can mean nightmares but believe me its not so difficult, trust me once you get the hang of it you will feel its more easy than other standard methods.

So as Everybody knows Google is one of the best platforms to work with and it can basically give you any information but once i started this integration most the options provided by google were kind of misleading because one site says to do this way and the other says to do that way.

Basically i was stuck, so as always using Shane Weedens blog for facebook i tried to do the same with google but by tweeking the code and the functionality but using the same concept i got to finish it.

The Total Flow is like

Client Accesses the Webseal URL     ---->> Clicks on Login with Google option.
Clicks on Login with Google Option  ---->> Goes to google login page(where you enter your creds)
Goes to google login page(where you enter your creds)  ---->> sends a code back to your application.
Fetch the code and send the code with client id back to google in a "POST" method  ---->> Google will reply back with token
Fetch the token and send it back to google in "GET" Method  ---->> Google will give the user data in JSON Format

Going to the Steps on how to do : -----

1. Google ID:-
Make sure you have a test id for google(You got to be a blockhead if you dont have an google id).

2. Register you OAUTH Credential:
The title might seem strange but dont worry.
Basically Google provides you the facility to create something called as Credential or application where you provide your application url,
Its just to identify that the response is sent back to the correct url and there is no malicious activity happening in between.

Login to the https://console.developers.google.com/apis/library and create a credential for your application.
So go ahead and create your application in it and make sure to note down the client id and client secret from it
In the Authorized Redirect uri make sure to give a proper url in my case it is given as https://<webseal ip/hostname>/auth/google/glogin.jsp
where auth/google is my junction in ISAM as well as my context root in the application and glogin.jsp is my application landing/home page.


3. JSP Call to Google OAUTH:
You can use the below code base for your application.
https://drive.google.com/file/d/0B-uIjGbTPyCXSjhBZW81UkROLTQ/view?usp=sharing
The zip file contains the Ecclipse Code which can be made to a war file and deployed on websphere application server.
The JSP code for making the call to google will look like below.

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"
import="com.tivoli.am.fim.demo.AccessTokenRetriever"
import="com.tivoli.am.fim.demo.ResourceRetriever"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Pragma" content="no-cache">
<title>Facebook Login</title>
<%
String appid = "987654321.apps.googleusercontent.com";
String appsecret = "123456789";
String redirectURL = "https://demowebseal.com/auth/google/glogin.jsp";
String email = null;

String code = request.getParameter("code");
String token = request.getParameter("access_token");

if (code == null) {
// initiate authorization flow
String authorizeURLStr = "https://accounts.google.com/o/oauth2/auth?client_id=" + appid
+ "&approval_prompt=force&redirect_uri=" + redirectURL
+ "&response_type=code&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&state=profile";
response.sendRedirect(authorizeURLStr);
} else {

String accessTokenURLStr = "https://accounts.google.com/o/oauth2/token";

AccessTokenRetriever atr = new AccessTokenRetriever();
String accessToken = atr.getAccessToken(accessTokenURLStr, code);

String resourceURLStr = "https://www.googleapis.com/oauth2/v1/userinfo?access_token=" + accessToken;
ResourceRetriever rr = new ResourceRetriever(resourceURLStr);
email = rr.getEmail(resourceURLStr);

// use the email address as a response header and redirect to the epac CGI
response.setHeader("am-eai-user-id", email);
response.setHeader("am-eai-redir-url", "https://demowebseal.com/cgi-bin/epac");
}
%>
</head>
<body>
If you see this, you haven't set the trigger URL properly in WebSEAL's
config file.
<br /> User email address is:
<%=email%>
</body>
</html>

4. Installation and Configuration of Custom googleauth/EAI application:
Download the googleauth zip file from the below url
https://drive.google.com/file/d/0B-uIjGbTPyCXSjhBZW81UkROLTQ/view?usp=sharing
The zip file contains an ecclipse project, its a sample code which uses only email as the userid or iv-user value of the ISAM.
The jsp file contains the client secret and client id modify it with your google application value and deploy the application as a war file over Websphere or any application server.
In my case i have deployed it on websphere and gave the context root as "auth/google/". Created a Unauth transparent junction for this application in webseal and added the google certificates in websphere.
Make sure you have all the certificates including intermediate certificates of accounts.google.com host for 443 port.

In ISAM provide the below values to make googleauth application as a EAI trigger url.

eai-auth = https
eai-pac-header = am-eai-pac
eai-pac-svc-header = am-eai-pac-svc
eai-user-id-header = am-eai-user-id
eai-auth-level-header = am-eai-auth-level
eai-xattrs-header = am-eai-xattrs
eai-redir-url-header = am-eai-redir-url
retain-eai-session = no
trigger = /auth/google/glogin.jsp*

With this you are done with the setup.

For testing this solution make sure you provide a link to logging in with google option in your webseal login page and provide the url as below.
https://<websealname>/auth/google/glogin.jsp

The flow of this will look like below

This should take you to google login page for credentials.
Provide your creds and it will ask for permission to access you profile details basically your email, first name, last name etc.
Google auth code will get the request back as provided by the redirect uri in the request with a code.
Fetch the code and send it back in POST request to google for getting the token which will expire in 3600 seconds.
Google auth code will get the token and pass it back to google requesting for user details.
which will sent back in json format, decode the json and get the required value and set it as the iv-user header for webseal.


References Used:

https://developers.google.com/api-client-library/java/google-api-java-client/oauth2#android
https://github.com/google/google-oauth-java-client
https://www-304.ibm.com/connections/blogs/sweeden/entry/facebook_authentication_to_webseal?lang=en_us


Do let us know in the comments if you have any troubles in implementing this solution.
Peace Out......

Wednesday, 16 March 2016

Deleting TAM/ISAM Users from registry

Sometimes runtime configuration(policy Server in Appliance) fails (or partially configured) in TAM/ISAM due to some issues.

When the users tries to reconfigure it again, ISAM throws an error message its already configured but it will not be in running state.

So its better to delete the default user entries created by TAM/ISAM before reconfiguring it.

Below are the commands to delete the default ISAM users(created during the runtime configuration) from the registry before reconfiguring it.

cd /opt/ibm/ldap/V6.3/bin
./idsldapdelete -D cn=root -w <password> cn=Subdomains,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Resources,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=ResourceGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Default,cn=Policies,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=SecurityGroup,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=SecurityGroup,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=ivacld-servers,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=remote-acl-users,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=SecurityMaster,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Policy,cn=Policies,principalName=sec_master,cn=Users,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Policy,cn=Policies,principalName=ivmgrd/master,cn=Users,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Policies,principalName=sec_master,cn=Users,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Policies,principalName=ivmgrd/master,cn=Users,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=ivmgrd-servers,cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=ivmgrd-servers,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=iv-admin,cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=iv-admin,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=secmgrd-servers,cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=secmgrd-servers,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=webseal-servers,cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=webseal-servers,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=webseal-mpa-servers,cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=webseal-mpa-servers,cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=ivmgrd/master,cn=SecurityDaemons,secAuthority=Default
./idsldapdelete -D cn=root -w <password> principalName=ivmgrd/master,cn=Users,secAuthority=Default
./idsldapdelete -D cn=root -w <password> principalName=sec_master,cn=Users,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Users,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Groups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=SecurityGroups,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=Policies,secAuthority=Default
./idsldapdelete -D cn=root -w <password> cn=SecurityDaemons,secAuthority=Default
./idsldapdelete -D cn=root -w <password> secAuthority=Default


./idsldapsearch -D cn=root -w <password> -b 'secAuthority=Default' -s sub '(objectclass=*)'


Thanks,
Nandavaram Pavan Kumar

Monday, 27 July 2015

4 Simple steps to Configure Passthough Authentication in TDS and Configuring the same to ISAM.

Firstly, Thank you all for the Great Responses and Awesome Support Shown to this blog 
If you have any doubts or issues about the Posts please do comment and we would get back to you at the Earliest.
Thanks and Keep Supporting ............

Now Lets get to the Matter in hand.

Everyone in the current corporate jungle is always looking for an extra piece of security to safe guard their corporate information

For satisfying the strict mandatory security conditions with an ease of access portfolio in mind an IDM Component is designed to provide a lot of extra functionalities to over come them.
and a Product like IBM is no exception, 

One of those Functionalities is the support of Passthrough Authentication.
Pass-through authentication is a mechanism which allows a client to bind to a directory server even if the user credential is not available locally. Using this mechanism the server attempts to verify the credentials from another external directory server or a pass-through server on behalf of the client

So, In much simpler ways - 
If you are using TDS as a user base to store User Details for an application like ISAM or any other product, But you have all your user details in an AD or any other directory server and you want to leverage that information.

In this case i am configuring a passthrough from TDS to AD.
What happens is that when any system tries to validate your USERID and Password from TDS. 
The TDS gets the bind request and knows the passthrough is configured then in this case the TDS connects to the AD machine and gets the password and validates it with the user provided password, but the TDS does not store any password information and all the password information is stored in the passthrough server(In this case the AD) rather than the TDS.

Ok I know that you if you are reading this page then you have already done your research and dont want to hear all this again,
So without further adieu the steps to configure Passthrough authetication from TDS/SDS to AD:

There are lot of ways for configuring passthrough but the below steps are one of the easy ones:

Enabling Pass through authentication from WebAdmin(IDSWebApp)

Step 1: enable Passthrough authentication option on your TDS/SDS:
If you are doing it through WebAdmin console then after logging in expand the Server Administration and click on Manage Security Properties and click on Passthorugh authetication TAB and select the Passthrough authentication checkbox for enabling it.

Step 2: Adding the details of the Passthrough server(AD):
Click on Add Button and enter the details of the Passthrough server like the host name and port and in the DN enter the suffix in the TDS for which you want the Passthrough enabled.

Step 3: Now Click on Next and in the next screen and check the option Enable Attribute Mapping. 
Enter the Bind Credentials of the Passthrough(AD) server and click on search base and select the OU in the Passthrough server you want to configure to.
In the Attribute for this directory server make sure to select an attribute that is present in the TDS like CN,SN,uid or any unique attribute in TDS.
In the Attribute from the Passthrough Server select an attribute that is present in the Passthrough Server(AD) like sAMAccountName,UserPrincipleName e.t.c.
The Attribute might not showup in the dropdown so make sure to enter them manually.
Click on Finish.

Step 4: Restart the TDS Instance. The server restart should be enough.


Enabling Passthrough authentication from Command Line:

This is my favourite as it is very easy and very clean.
Step 1: Browse to the bin folder of your TDS installed Location and create an LDIF file with the below (only the ones that are in Bold) Entries in it.
In my case i created a file called PTA.ldif


dn: cn=Configuration
changetype: modify
replace: ibm-slapdPtaEnabled
ibm-slapdPtaEnabled: true

dn: cn=Passthrough Server1, cn=Passthrough Authentication, cn=Configuration
changetype: add
cn: Passthrough Server1
ibm-slapdPtaURL: ldap://<PTA hostname>:<port>
ibm-slapdPtaSubtree: o=sample1
ibm-slapdPtaAttrMapping: uid $ userPrincipalName
ibm-slapdPtaSearchBase: c=in,dc=com
ibm-slapdPtaBindDN: <bind DN>
ibm-slapdPtabindPW: <bind password>
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdPta
objectclass: ibm-slapdPtaExt



o=sample1 -- is the Suffix in the TDS instance on which you want the Passthrough Authentication enabled.
ibm-slapdPtaAttrMapping -- "uid" is the Attribute from the TDS and "userPrincipalName" is the attribute from the Passthrough Server(AD).
c=in,dc=com -- is the Suffix in the AD on which you want the passthrough to be configured to.

Step 2: Execute the Below command with your TDS instance details.
ldapmodify -h <hostname> -p <port> -D <adminDN> -w <adminPWD> -f <Location of the PTA.ldif file>

Step 3: Restart the TDS Instance.

Step 4: Have a Cup of Coffee or a bottle of Beer or both as you have successfully configured the Pass Through Authentication.


Note: You would need to keep the Password field in LDAP to Empty as the password is to be fetched from the Passthrough Server(AD)

Special Note: Make sure that you have all the required ports open in the firewall or else your Coffee/Beer can turn into a Nightmare at office.


Now For Configuring the Same to the ISAM.
While Configuring the Policy Server make sure to configure the LDAP suffix to the suffix on which the Passthough is enabled.


After configuring the Policy server and webseal instance modify the property auth-using-compare to no in the ivmgrd.conf and the webseald.conf file.

Make sure to restart the Policy Server and the Webeal for the changes to be reflected Properly.

Monday, 20 October 2014

Linux red hat 6.4 Pre-requisities for installing any ibm product (IBM Db2, TDS, ISIM, ISAM-eb, ISAMESSO, TFIM, TSPM, Websphere)

For Linux red hat 6.4, ensure as a first task install the below 32 and 64 bit packages. This is irrespective of the product you are installing.
 
64 bit:
yum install compat-libstdc++-33-3.2.3-69.el6.x86_64
yum install compat-db-4.6.21-15.el6.x86_64
yum install libXp-1.0.0-15.1.el6.x86_64
yum install libXmu-1.1.1-2.el6.x86_64
yum install libXtst-1.2.1-2.el6.x86_64
yum install pam-1.1.1-13.el6.x86_64
yum install libXft-2.3.1-2.el6.x86_64
yum install gtk2-2.18.9-12.el6.x86_64
yum install gtk2-engines-2.18.4-5.el6.x86_64
 
32 bit:
yum install compat-libstdc++-33-3.2.3-69.el6.i686
yum install compat-db-4.6.21-15.el6.i686
yum install libXp-1.0.0-15.1.el6.i686
yum install libXmu-1.1.1-2.el6.i686
yum install libXtst-1.2.1-2.el6.i686
yum install pam-1.1.1-13.el6.i686
yum install libXft-2.3.1-2.el6.i686
yum install gtk2-2.18.9-12.el6.i686
yum install gtk2-engines-2.18.4-5.el6.i686

Thursday, 9 October 2014

Form Based Single Sign on configuration in TAM


Form Based Single Sign on configuration in TAM :-

Forms Single Sign On:

1. The back-end application is unaware that the login form is not

coming directly from the user

2. WebSEAL supplies data required by the login form and submits the

login form on behalf of the user.

3. WebSEAL saves and restores all cookies and headers.

4. The user is unaware that a second login is taking place.

5. The back-end application is unaware that the login form is not

coming directly from the user.

TAM provides a by default fsso(Forms Single Sign On) configuration template file.

Location of Template conf file:

Unix

/opt/pdweb/etc/fsso.conf.template

Windows:

C:\Program Files\Tivoli\PDWeb\etc\fsso.conf.template

The fsso.conf file is created according to the Backend login.form.

Configuration:fsso.conf

[forms-sso-login-pages] stanza

1.The forms single signon configuration file must always begin with

the [forms-sso-login-pages] stanza.

2.The stanza contains one or more login-page-stanza entries that

point to other custom-named stanzas that contain configuration

information for the login pages found on the back-end application

server

 For example:

 [forms-sso-login-pages]

 login-page-stanza=tds

Custom login page stanza

1.For each value defined in [forms-sso-login-pages] results in

Creation of customized stanza used to intercept a particular URL

pattern.

Example:

 login-page = /IDSWebApp/IDSjsp/Login.jsp

 login-form-action = IDSWebApp/IDSHome

 gso-resource = TDS_GSO

 argument-stanze = args-for-tds-login-page.

Custom login page stanza: login-page

1.The value of the login-page stanza entry is a regular expression

that WebSEAL uses to determine if an incoming request is

actually a request for a login page

2.WebSEAL intercepts this request and begins the forms single

signon processing

3. Only one login-page stanza entry is allowed in each custom

login page stanza

Example:

 login-page = /cgi-bin/getloginpage*

Custom login page stanza:login-form-action

1.This stanza entry is used to identify the login form on the

intercepted page

2.Only one login-form-action stanza entry is allowed in each stanza

3.The value is a regular expression that is compared against the

contents of the "action" attribute of the HTML "form" tag

4. If multiple "action" attributes on the page match the regular

expression, only the first match is accepted as the login form

login-form-action = *

Argument Stanza

1. The custom argument stanza contains one or more entries in the

following form: name = method:value

2.name

 The value of the name variable is set to equal the value of the

"name" attribute of the HTML "input" tag. For example:

 <input name=uid type=text>Username</input>

3.This variable can also use the value of the "name" attribute of

the HTML "select" or "textarea" tags.

method:value

4.This combination retrieves the authentication data required by

the form. The authentication data can include:

5. Literal string data

 string:text

 The input used is the text string.

6. Value of an attribute in the user's credential

 cred:cred-ext-attr-name

method:value

7.GSO user name and password

 gso:username

 gso:password

The input is the current user's GSO username and password

(from the target specified in the custom login page stanza).

8. It is not necessary to specify hidden input fields in this stanza.

These fields are automatically retrieved from the HTML form and

submitted with the authentication request.

Example A:

 [args-for-tds-login-page]

 idsuserid = gso:username

 idspasswd = gso:password

Example B:

 [args-for-tds-login-page]

 idsuserdn = cred:azn_cred_principal_name

 idsuserpwd = string:Passw0rd

To enable FSSO create junction with –S option and Specify the

full path of the fsso.conf file

 Example:

server task default-webseald-tam create –t tcp –h tam –p 9080 -b

gso –T TDS_GSO –S /opt/pdweb/etc/tds_fsso.conf –i

/tds_gso_junct

 * tds_fsso_conf – is the conf file

 * TDS_GSO is the GSO resource

 * /tds_gso_junct is the junction name.

Configure your user for the GSO and give the GSO creds to be used for IDSWebApp.

With this your IDSWebApp url is configured for fsso(Forms Single Sign On).

Access the url and webseal login page will pop up enter the creds and you should be automatically logged in to IDSWebApp.