How to invoke an External JAR/JAVA Code in IGI

How to invoke an External JAR/JAVA Code in IGI

The Up and Coming Access Governance tool from IBM called IGI/ISIG is one of the most interesting tools that i got a chance to work on. The Tool still has a room for improvement but it is becoming a strong contender for other access governance tools like sailpoint,savyint and aveksa.

As the tool is still in a development phase there is not much documentation available online.
This option was something we implemented for a client but the functionality was a pure trial and error. Thankfully it worked, Even before IBM came back with a solution :-) .No Disrespect but the reply from IBM regarding a service request on IGI is very slow...

So, the First thing we need to understand is that all the rules(basically workflows) in IGI is written in JAVA. Yep, umight be thinking java....y so retro can they design a better gui model like a workflow in ISIM or sailpoint....sadly, we have to make it work as it is.

Actually for most of the IAM'ers who understand JAVA it will be very benefecial as most of the custom extensions in most IAM products are generally written in JAVA.

Basically what we have to do is to deploy our java code as a JAR file and deploy it on the appliance using the below steps:
1. Login to IGI VA Admin Console.
2. Browse to Configure>>Custom File Management>>lib.
3. Click the button upload and select the JAR file that u want to upload.
4.  After Upload make sure to restart the IGI server and not the complete appliance only the server, if in case u have a cluster make sure to synchronize the servers using cluster management and then restart the cluster machine IGI server as well.

Now your JAR has been successfully uploaded and u can call ur JAR and the custom java Code that u want to call from it.

For my Example i used a ojdbc.jar and wrote a java code in the rule to write to a Oracle table and for connection to DB i used a property file which was deployed using the same way as my JAR file.

Before u write the code make sure to import your classes in the import option provided in the rules, if not it will fail
below is the code that i have used in my environment.

when
    eval( true )
then
Connection con = null;
Properties prop = new Properties();
InputStream input = null;
input = new FileInputStream("/opt/isig/IDEASPlatformEnvCustom/lib/db.properties");
prop.load(input);
Class.forName("oracle.jdbc.driver.OracleDriver");  
String hostname=prop.getProperty("dbhostname")+"";
String port=prop.getProperty("dbport")+"";
String service=prop.getProperty("dbservice")+"";
String dbuser=prop.getProperty("dbuser")+"";
String dbpwd=prop.getProperty("dbpwd")+"";
String dbtable=prop.getProperty("dbtable")+"";
String sqlurl="jdbc:oracle:thin:@"+hostname+":"+port+":"+service;
    con=DriverManager.getConnection(sqlurl,dbuser,dbpwd);  
      
    //step3 create the statement object  
    Statement stmt=con.createStatement();  
      
    //step4 execute query  
    ResultSet rs=stmt.executeQuery("SELECT * FROM "+dbtable+" ");  
   System.out.println(rs);
    while(rs.next())  {
    System.out.println(rs.getString(1)+"    "+rs.getString(2));   
UserBean thisUser = UtilAction.findUserByCode(sql, rs.getString(2));
//You can write your code here on what to do with the data u get from the table.
}
   con.close(); 

Basically IGI gives u the option on customizing the Rules just like any other tool 

Adding Multiple Access Owners for a Permission and set a IGI Certification Campaign for them

For the Past few months i had the chance to get my hands on the IBM IGI Product, So far the product seemed good but it is still a little backward considering other governance tools like aveksa and sailpoint.
Its got the potential but it purely depends on the developers at IBM on which way it is to go...but from my past experience with crossideas i have to say its grown alot... really alot...

Ok so moving to the topic...
In IGI the default visible options in GUI allows only one accessowner to be added to a permission(basically a group or access in AD or Linux etc).

But sometimes like other tools we might need to configure multiple owners for a permission, by default the option of configuring multiple owners are generally not enabled.
To enable it we will have to twerk the tool a little...

Follow the below steps for it....

1. Login to IGI. Go to Access Governance Core > Configure > Admin Roles. Check if 2 IT Roles with the name “UserReviewer” and “EntitlementReviewer” for application “AccessCertifier” are already present. These two roles should be present by default unless they are forcibilly removed..
2. if the roles are not there then do not panic just create it for application accesscertifier.
3. Now create a Business Role with the name “Entitlement Owner”.
4. Browse to the Organizational Units Tab click on Actions tab and click on Add and select the top most OU and click on OK button.(This part is option if u are using any rule to push this information then u will certainly need to do this if u are doing it manually then u can avoid it)
5. Select the option Hierarchy and make sure enabled is Yes and click on OK button.
6. Select the Entitlement Owner Business Role and in the Management Tab add the two roles UserReviewer and EntitlementReviewer ITRoles using the Action button.
7. Now click on user tab and search for the users to whom u want to add the owner for...now on selecting the user it will show all the permissions, basically u can select the permission and add them for which the selected person will be the owner of...

So if u want to automate this can u do it.....yes we can ....basically u will have to write a rule to do this..

To use a access owner certification go to the reviewers tab u have to select the option entitlement under entity...
Basically it will initiate a campaign for all the entitlements selected under this campaign and set their reviewers as the ones set as their owners.

Now the question is what happens to the default owners that are set on the permission directly rather than the admin role...well they will also be considered as the access owner for that entitlement and they will also get a review for that entitlement...

IBM Verify App integration with ISAM for web - Password less Authentication

So, Good Old IBM Comes up with a new strategy for Mobile based Authentication system for ISAM.
For all the people who been using Google Authenticator can switch to IBM Verify App, It is intended to make it easier and more IBMer view...

I tried my hand on the new IBM Verify app with the intention of completely turning it inside out and trying out everything possible with it and my favourite ISAM for web..

It took sometime for me to understand and get used to the new Verify App, Although there are a few issues like all mobile based apps, it still feels good to use it...

Lets get to the Configurations of it....

Basically, this method can only be used if u have ISAM version of 9.0.2.1 or above....preferably 9.0.3...
If u are using base version of 9.0.2.1 then it will be pretty straight forward but if are using an upgraded version then u will have to replace your old html file templates to the new ones...

This basic setup needs generally two webseal environments...
the primary one where u will configure all the target applications and the other one for mobile....
These two webseals will work in sync to get ur communication to the Mobile App established...
IBM has given a very good explanation on their site about how it works so i will not be going into detail on it...

So lets start with it...

Firstly, load the certificate for the appliance in your pdsrv key store.
Browse to Manage System Settings> SSL Certificates..
select the pdsrv key store and click on manage and select the Edit SSL Certificate Database.
Select Signer Certificates and click on manage option and select load..
In the server field enter localhost, port give 443, and label give runtime...
this step will load the default localhost certificate to the pdsrv key store.

Now Browse to the reverse proxy page and edit the configuration files of both the default and mobile webseals to keep the below value in the file..
force-tag-value-prefix = no

Deploy and restart both the webseals..

Browse to the Secure Access Control > Global Settings > User Registry
Select the easuser and set a password for the user - In my case i am setting the password as "Passw0rd"
Deploy the changes..

Now Open the Default Webseal configuration file and make the below changes in it:

In the Server stanza make the below changes:

[server]
…
http-method-disabled-local = TRACE,PUT,DELETE,CONNECT
http-method-disabled-remote = TRACE,CONNECT


In the Server stanza make the below changes:

[session]
…
user-session-ids = yes

Add the following stanza to the end of the configuration file to manage cookies created by AAC Runtime so they are not returned to the browser

[junction:/mga]
reset-cookies-list = *ac.uuid,*JSESSIONID*
managed-cookies-list = *ac.uuid,*JSESSIONID*

Enable EAI authentication. Specify that when EAI is used for a re-authentication, the original session should be maintained. Specify that EAI should be able to override where the user is directed after authentication completes

[eai]
eai-auth = https
…
retain-eai-session = yes
eai-redir-url-priority = yes

Add the following trigger URLS for EAI:

[eai-trigger-urls]
trigger = /mga/sps/oauth/oauth20/session*
trigger = /mga/sps/auth*
trigger = /mga/sps/authservice/authentication*
trigger = /mga/sps/authsvc*
trigger = /mga/sps/apiauthsvc*

Add the following entries to the azn-decision-info stanza. This tells the Reverse Proxy what information from incoming requests to make available to the authorization engine

[azn-decision-info]
Accept = header:Accept
Accept-Charset = header:Accept-Charset
Accept-Encoding = header:Accept-Encoding
Accept-Language = header:Accept-Language
Authorization = header:Authorization
Cache-Control = header:Cache-Control
Connection = header:Connection
Content-Type = header:Content-Type
Host = header:Host
HTTP_HOST_HDR = header:host
HTTP_REQUEST_SCHEME = scheme
HTTP_REQUEST_METHOD = method
HTTP_REQUEST_URI = uri
HTTP_AZN_HDR = header:authorization
HTTP_CONTENT_TYPE_HDR = header:content-type
HTTP_TRANSFER_ENCODING_HDR = header:transfer-encoding
Missing = header:Missing
Pragma = header:Pragma
Transfer-Encoding = header:Transfer-Encoding
User-Agent = header:User-Agent
X-Requested-With = header:X-Requested-With
method = method
rspcode = header:rspcode
scheme = scheme
uri = uri

Add the following to the obligations-urls-mapping stanza. This maps incoming obligations to the browser endpoint of the Advanced Access Control authentication service.
This is actually different from how the the MMFA config tool sets things up, but for our browser-channel Reverse Proxy we do actually want the HTML-based authsvc URL rather than the apiauthsvc

[obligations-urls-mapping]
urn:ibm:security:authentication:asf:* = /mga/sps/authsvc

Configure Web Socket support. This is needed so that clients can connect to the Web Socket service that MMFA uses for notification of transaction completion.

[websocket]
max-worker-threads = 20
jct-read-inactive-timeout = 300
clt-read-inactive-timeout = 300
jct-write-blocked-timeout = 300
clt-write-blocked-timeout = 300

Save the Configuration file and deploy the changes and restart the webseal.

Now access the mobile webseal configuration file and make the below changes in it....

Remove PUT and DELETE from http-method-disabled-remote to allow these methods for non-local junctions

[server]
…
http-method-disabled-local = TRACE,PUT,DELETE,CONNECT
http-method-disabled-remote = TRACE,CONNECT

Enable creation of user session IDs for each session

[session]
…
user-session-ids = yes

Add the following stanza to the end of the configuration file to manage cookies created by AAC Runtime so they are not returned to the browser:

[junction:/mga]
reset-cookies-list = *ac.uuid,*JSESSIONID*
managed-cookies-list = *ac.uuid,*JSESSIONID*

Disable form-based login. Mobile devices will only authenticate with OAuth.

[forms]
forms-auth = none

Configure the Reverse Proxy to internally follow redirects related to calling the Authentication Service (in response to Obligations). This is needed because typically REST clients don't handle redirects well.

[server]
# These will allow WebSEAL to internally follow redirects for authentication
follow-redirects-for = GET /mga/sps/apiauthsvc*
follow-redirects-for = PUT /mga/sps/apiauthsvc*

Enable OAuth authentication:

[oauth]
oauth-auth = https
default-fed-id = https://localhost/sps/oauth/oauth20

Provide the basic-auth-user for authentication to the OAuth token validation endpoint. Add the other lines specified to set up the connection:

[tfim-cluster:oauth-cluster]
basic-auth-user = easuser
server = 9,https://localhost/TrustServerWS/SecurityTokenServiceWST13
basic-auth-passwd = Passw0rd
ssl-keyfile = pdsrv.kdb
ssl-keyfile-stash = pdsrv.sth

Allow headers to be used for end-user sessions (rather than only for multiplexing proxy sessions):

[session]
require-mpa = no

Enable sessions using the Authorization header as the session index (rather that a session cookie):

[session-http-headers]
Authorization = https

Click Save to save the updated configuration.
Deploy the changes and restart both the default and mobile Reverse Proxy instance.

Now create a standard junction /mga for both default and mobile webseals with the below values...
Junction  - /mga
SSL - yes
Target Backend Server hostname - localhost
port - 443
HTTP Basic Authentication Header - Ignore
headers to be passed - iv-user, iv-groups, iv-creds
set HTTP Header Encoding as UTF-8 URI Encoded
Enable the junction cookie
set Junction Cookie Javascript Block as Inhead
also select the check boxes for Include session cookies and Insert Client IP Addresses

make sure to create the junction in both default and mobile webseals

There are a few set of ACL's that need to be created..
To make it much easier i have given the commands that we need to run for creation of ACL and attaching them to the corresponding Object Spaces.

acl create isam_mobile_anyauth
acl modify isam_mobile_anyauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_anyauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_anyauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_anyauth set any-other Tr
acl modify isam_mobile_anyauth set unauthenticated T
acl attach /WebSEAL/myisam-default/mga/sps/auth isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/xauth isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/clients isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/common/qr isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/html isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/html isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/ac isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/wssoi isam_mobile_anyauth

acl attach /WebSEAL/myisam-default/app/mobile-demo isam_mobile_anyauth
acl attach /WebSEAL/myisam-mobile/mga/sps/oauth/oauth20/logout isam_mobile_anyauth
acl create isam_mobile_unauth
acl modify isam_mobile_unauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_unauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_unauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_unauth set any-other Tr
acl modify isam_mobile_unauth set unauthenticated Tr

acl attach /WebSEAL/myisam-default/mga/sps/authsvc isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/authservice/authentication isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/authorize isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/session isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/token isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/static isam_mobile_unauth
acl attach /WebSEAL/myisam-default/app/mobile-demo/theme isam_mobile_unauth
acl attach /WebSEAL/myisam-default/app/mobile-demo/oauth/oauth2Client.jsp isam_mobile_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/details isam_mobile_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/oauth/oauth20/token isam_mobile_unauth

acl create isam_mobile_nobody
acl modify isam_mobile_nobody set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_nobody set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_nobody set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_nobody set any-other T
acl modify isam_mobile_nobody set unauthenticated T
acl attach /WebSEAL/myisam-default/mga isam_mobile_nobody
acl attach /WebSEAL/myisam-mobile/mga isam_mobile_nobody
acl create isam_mobile_rest
acl modify isam_mobile_rest set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_rest set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_rest set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_rest set any-other Tmdr
acl modify isam_mobile_rest set unauthenticated T

acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/otp isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/device isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/questions isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/grant isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/authenticators isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/auth_methods isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/qr_code isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/transactions isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/websock/mmfa-wss isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/otp isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/device isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/questions isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/grant isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/authenticators isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/auth_methods isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/qr_code isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/transactions isam_mobile_rest

acl create isam_mobile_rest_unauth
acl modify isam_mobile_rest_unauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_rest_unauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_rest_unauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_rest_unauth set any-other Tmdrxl
acl modify isam_mobile_rest_unauth set unauthenticated Tmdrxl
acl attach /WebSEAL/myisam-default/mga/sps/apiauthsvc isam_mobile_rest_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/apiauthsvc isam_mobile_rest_unauth

After all this we come to one of the most important concepts in this configuration (i.e) The SCIM Configuration(System for Cross Domain Identity Management):
The name might confuse but its one of the most interesting concepts in the new version of ISAM. This configuration can be used to connect to different types of targets like(LDAP,Oracle,DB2,Webservices etc)
In our case we will use this functionality to verify if the user entered is in the LDAP or not...

Browse to secure accees control > Global Settings > Server Connections.
Click on new and select LDAP option...
In the New connection modal window enter the name and description.
On the server tab make sure to give your ldap details of where the user details exists.
In this case i am not using ssl but in case if u are using ssl make sure to add the certificate in the keystores and point that keystore for certificate.
basic details for connecting to LDAP include hostname, port, userdn(i have used cn=root for full priveleges but its better to use an id which has atleast lookup privileges) and password..
In case if u are using the embedded ldap then its better to use "cn=root,secAuthority=Default" as the userdn...
Save the Changes and Deploy...

Now browse to Secure Access Control > Manage > SCIM Configuration....
Select the User Profile Tab..
In the Server Connection select the server connection u created in the above step and in the search suffix and user suffix its best to give the top most OU.
Click on save and if there is any error in the server details that u have provided in the server connections the connection failed error will be displayed..
If all the details are correct and isam is able to communicate to the LDAP then it will give a message to deploy the changes...

Now switch to ISAM User tab in the SCIM Configuration page...
Select the check box for both Enable ISAM Integration and Update Native Users and inthe ISAM User Registry select the Server connection that u have created above.
Save and deploy the changes...

Browse to the Reverse Proxy page and create a junction called /scim junction in the default and mobile webseals with the below details...
Create a transparent junction /scim for both default and mobile webseals with the below values...
Junction  - /scim
create transparent path junction - yes
SSL - yes
Target Backend Server hostname - localhost
port - 443
In Basic Authetnication tab select the checkbox for enabling basic authentication and give the credentials for easuser in the username and password field.
HTTP Basic Authentication Header - Filter
headers to be passed - iv-user, iv-groups, iv-creds
set HTTP Header Encoding as none
set Junction Cookie Javascript Block as none
also select the check boxes for Include session cookies and Insert Client IP Addresses

save and it should show a message in blue colour saying junction created successfully.

Edit the Webseal configuration for both the webseals(default and mobile) to make the changes in the configuration file...

In the [filter-content-types] stanza add the following entry:
[filter-content-types]
type = application/scim+json

In the [script-filtering] stanza, enable script filtering and replacing absolute URLs with absolute URLs:
[script-filtering]

script-filter = yes
#rewrite-absolute-with-absolute = no
rewrite-absolute-with-absolute = yes

Deploy and restart the webseals...
Make sure u do these in both the webseals(default and mobile)

Enter the following command to attach an ACL allowing all REST methods to the SCIM endpoint associated with the mobile Reverse Proxy instance
acl attach /WebSEAL/myisam-mobile/scim isam_mobile_rest

Although not strictly required for MMFA, we will also enable all REST methods to the SCIM endpoint associate with the default Reverse Proxy instance. This allows SCIM modify functionality to be demonstrated via the built-in test application. Without this, only GET requests are possible.
acl attach /WebSEAL/myisam-default/scim isam_mobile_rest

Create SCIM admingroup and two users named scimadmin and testuser using the below commands...

group create adminGroup cn=adminGroup,dc=iswga adminGroup
user create scimadmin cn=scimadmin,dc=iswga scimadmin scimadmin Passw0rd
user modify scimadmin account-valid yes
group modify adminGroup add scimadmin
u c testuser cn=testuser,dc=iswga Test User Passw0rd
u m testuser a yes

the above values will change according the type of ldap u are using, in my case i am using the embedded LDAP so the suffix dc=iswga

Test the SCIM configuration using the inbuilt SCIM demo Application...

Browse to Manage System Settings > System Settings > Advanced Tuning Parameters...
Select the new button and Enter scim_demo_enabled as the Key and true as the Value. Click Save Configuration.
Deploy changes using the link in the yellow warning message.

Access the url https://myisam/scim/demo.html
Here myisam refers to the default webseal...
Login with testuser created above using the commands
Now in the general tab check the values being displayed if the values are of the user logged in or not...
click on isam tab and verify if the values being displayed are the values of the user logged in or not...

If these details are correct the SCIM Configuration is Successfull.

Now login back to the VA Admin console and browse to the secure access control > Policy > API Protection...
Click on Create button and create a new API Protection with the below values...

Name : Authenticator
under grant types only enable the check box Authorization Code...
Expand the Token Management section and check the check-box for Enforce single-use authorization grant.
Click Save at the top of the screen.
Deploy changes using the link in the yellow warning message.

Browse to the Clients tab on the API Protection page and create a new client with the below values.
By default the Client ID is a randomly generated string but that complexity is not required here.
Enter AuthenticatorClient as the Client ID.
Enter Authenticator Client as the Client name.
Clear the Confidential checkbox. An MMFA client is generally running on in an untrusted environment (i.e. a mobile device) and so a client secret has little value (and in any case we only want to allow a specific redirect).
Enter the following as the Redirect URI:
https://myisam/mga/sps/mmfa/user/mgmt/html/mmfa/qr_code.html?client_id=AuthenticatorClient
Here myisam refers to the default webseal...
This makes sure that after the OAuth Authorization Grant is generated control is returned to the MMFA registration function.
Enter a company name...in my case i have used IBM as the Company name
and click OK.
Deploy the changes using the link in the yellow warning message

Now Comes the most important part of this exercise the MMFA endpoint configuration.

Navigate to Secure Access Control > Manage > MMFA Configuration.
Click on Wizard to begin configuration.

Set the Client ID to AuthenticatorClient, and the Reverse Proxy URL to https://<ip or hostname of your mobile webseal>:<port on which your webseal is running on>
make sure to give the correct the ip and port, any issues in it will lead to improper configuration and your whole configuration will fail....
Click on Next and it will display the discovery endpoint, token endpoint, HOTP Shared secret Endpoint and TOTP Shared secret endpoint... all these values will be prefilled..
Click on Next and this time it will show the enrollment endpoint and the transaction endpoint..click on next
now it will show the endpoint prefix... all these will be prefilled except the first box...
now click on save and deploy the changes...

Navigate to the Discovery Mechanisms tab on the same page and click Add.
Select urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:fingerprint from the drop-down list and click Save.
Repeat this step to add the following additional mechanisms:
• urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:user_presence
• urn:ibm:security:authentication:asf:mechanism:totp

Navigate to the Custom QR Code Options menu, and click Add.
Enter ignoreSslCerts as the Key and true as the Value.
This option will be added to registration QR codes and instructs IBM Verify that it is OK to connect to SSL endpoints which do not host a valid SSL certificate. You would not set this in a production environment but we need it for our test system.
Click Save and deploy the changes...

Now it is time to test the full configuration....

Access the below url for registering the device...
https://myisam/mga/sps/mga/user/mgmt/html/device/device_selection.html
Here myisam refers to the default webseal...
This page shows all the new authenticators added to the user(i.e) all the devices registered for the user...
Click on Register new Authenticator button...

This will trigger a request to the below url....
https://myisam/mga/sps/oauth/oauth20/authorize?client_id=AuthenticatorClient&response_type=code&scope=mmfaAuthn
Here myisam refers to the default webseal...
if its doesnt redirect then there is an issue with the html file... In case of the upgraded system from an older version to the 9.0.3.0 version the html files will not be updated::::
So browse to Manage System Settings > secure Settings > File Downloads...
Now expand and go to acces control > pages > C > mga > user > mgmt 
Download the files design.css, common.js, device_selection.html, device_selection.js and style.css
Now browse to the secure access control > global settings > template files..
expand the  C > mga > user > mgmt and delete the files design.css, common.js, device_selection.html, device_selection.js and style.css...
Deploy the changes and now upload the new files that we downloaded from the file downloads option... 
design.css, common.js, device_selection.html, device_selection.js and style.css, upload them and deploy the changes...

It generally doesnt sync the new js files that were uploaded.. its better to restart the machine and try the url for device registration again....


After u click on the register new authenticator the page will redirect to a new page which contains the QR CODE...
Now scan the QR Code from the IBM VErify APP in your mobile..(u can download the free ibm verify app from the app store for ios and google play store for andriod devices)
Make sure your mobile can communicate to the webseal (i.e) either your mobile and webseal are in the same network or your webseal is exposed to the internet..
and also for all the dummies out there the app needs internet so please do connect to internet before doing this activity...

A success message is shown saying the device is successfully registered....
in case of error please check ur configurations again...

After it is successfully registered..on your mobile Touch Got it! to continue. You can now set up notifications – this allows IBM Verify to alert you when a new MMFA transaction is pending. Touch Notify Me and then Allow to enable.
You are now offered the option to enable the fingerprint authentication method, provided your device supports it. Touch Use Touch ID to continue (on mobile device). Present you fingerprint when prompted to unlock secure storage.

The fingerprint authentication method will work only onthose devices which have inbuilt finger censor in them...
sadly dowloading fingerprinst secure apps will not work for this..😒

Once it is successfully configured your mobile will show a success message now go to the accounts on your mobile and u will find a new account that got registered with the ipaddress/hostanme of your mobile webseal and the userid shown below that..
clicking on that will show the access code or otp which keeps on changing every 30 or 60 seconds...this can also be used as a otp generator also...i still havent tested this OTP Feature but will test if i can use this otp as a RSA token generator but that is for an other day... 😃


Now go back to the device selection url on your browser ...
https://myisam/mga/sps/mga/user/mgmt/html/device/device_selection.html
Here myisam refers to the default webseal...

it will show the authenticators tab the newly configured device will be shown with an id staring with uuid**********....click on the uuid********* and it will show the details that were obtained from your mobile phone...like the OS VErsion, fingerprint support and other details...

This Completes the device Registration using IBM Verify...

Password Less Login Scenerio using the IBM Verify App:

This scenerio will work based on the userid that is sent in the url..
We will read the username from a username parameter sent in the url to the Authentication Service.
Navigate to Secure Access Control > Policy > Authentication.

On the policies tab click New button to create a new authentication policy.

Enter MMFA Initiate Login Policy as the Name. This is the human-readable name for the policy.
Enter mmfa_initiate_simple_login in the Identifier box. This will be appended to the text already shown which makes the full identifier: urn:ibm:security:authentication:asf:mmfa_initiate_simple_login.
Enter a Description.
Ensure the Enabled checkbox is checked.
An authentication policy consists of one or more steps.

Click Add Step button to add the first step.
Select MMFA Authenticator mechanism from the drop-down list. Then click the properties icon next to it to bring up the properties editor.

In this first example, we will set up the most simple initiate policy possible by using fixed values for most parameters. we can use dynamic values to make things more interesting also and all these can be acheived in Authentication page using a combination of javascripts and authentication mechanism...
.
Select the checkbox next to contextMessage and set the value to Please verify login to myisam. This is the text that will be displayed to the user in the Authenticator Client application.

Select the checkbox next to mode. The default value of Initiate is what we want so don't change it. This tells the mechanism that it is initiating the challenge to the Authenticator Client.

Select the checkbox next to policyURI. Set the value to: urn:ibm:security:authentication:asf:mmfa_response_userpresence

This is Policy ID of the authentication policy that will handle the challenge response from the Authenticator Client. We are going to create this authentication policy in the next step.
The only parameter that is dynamic here is the username parameter. This species the user for which the challenge should be generated. Obviously this needs to be the user that we want to log in. We will read this value from a query string parameter of the request sent to the authentication service. The query string parameter is also named username.

Select the checkbox next to username. Select Request from the drop-down list for Source. This indicates that we will read from the incoming Request.

Enter urn:ibm:security:asf:request:parameter as the Namespace for the value. This is a defined namespace that provides access to query-string parameters of the incoming HTTP request.
Enter username as the Attribute Id. This is the name of the query-string parameter to use.
Click OK to close the parameters window.

Click OK to add the workflow step. Then click Save at the top of the window to save the Policy.
A warning is shown to indicate there is an undeployed change. There is no need to deploy yet though because we have more configuration to do

We have created a authentication policy for sending a request now we need to create another Authentication Policy that will handle the 2nd half of the MMFA process. It performs the challenge/response with the Authenticator Client and then marks the MMFA action complete.
Click the new button to create another new Authentication Policy.

Enter MMFA User Presence Response as the Name.
Enter mmfa_response_userpresence in the box for Identifier.
This makes the complete ID for this authentication policy urn:ibm:security:authentication:asf:mmfa_response_userpresence which matches what we configured as the policyURI in the "initiate" policy.
Enter a Description.

Ensure the Enabled checkbox is checked.
Click Add Step to add the first mechanism to the policy.
The first step in this policy handles the MMFA user presence challenge/response. This uses a pre-defined authentication mechanism called User Presence Approval. Select this from the drop-down list. There are no special properties we need to set.
Click OK to confirm addition of the User Presence Approval mechanism to the policy.
Click Add Step again to add a second step to the policy.
Select MMFA Authenticator from the drop-down list. This is the same mechanism that we used in the "initiate" policy but this time we are going to use it in "response" mode.
Click the properties icon to open the parameters screen.

The only parameter we need to set is the mode. Select the checkbox for mode and set the Value to Response using the drop-down list. This tells the mechanism that it is responsible for completing the MMFA process that was started in the "initiate" policy.
Click OK to close the parameters window.
Click OK to confirm addition of the MMFA Authenicator mechanism to the policy.
Click Save at the top of the window to save the new Authentication Policy.
Deploy changes using the link in the yellow warning message.

Our first MMFA Process is now ready to use. It will be triggered manually by calling the ISAM Authentication Service and requesting the "initiate" policy using its Policy ID.

Setting the Authentication levels:
In this case we will set the mobile login or the password less login mechanism as the higher priority than the password based mechanism...
By default, unauthenticated sessions are level 0, password authentication is assigned level 1 and EAI authentication (which is what the AAC Authentication Service uses) is assigned level 2. In this environment, we want to make MMFA authentication level 1 and password level 2. This requires a change in the Reverse Proxy configuration file.

Navigate to Secure Web Settings → Manage: Reverse Proxy,
Select the radio button for the default Reverse Proxy instance. Click on Manage and select ConfigurationEdit Configuration File from the pop-up menu. This will open the configuration file.
To find a location in this file, use the browser's search function. On Firefox this is activated using Ctrl-f.
Locate the [authentication-levels] stanza and make changes as below.
[authentication-levels]
#----------------------
# STEP UP
#----------------------
# authentication levels
#
# Syntax:
# level = <method-name>
…
#
level = unauthenticated
level = ext-auth-interface
level = password

The order of these levels assigns the authentication levels. With this setting, unauthenticated is 0, ext-auth-interface is 1, and password is 2. This order is important, and is required to allow the ext-auth-interface to be used for step-up authentication in the later advanced password-less login scenario.
Click Save to save the updated configuration.
Deploy changes using the link in the yellow warning message.
Restart the default Reverse Proxy instance.

Access the pdadmin console and execute the below command
acl attach /WebSEAL/myisam-default/mga/websock/mmfa-wss isam_mobile_rest_unauth
object modify /WebSEAL/myisam-default/app set attribute HTTP-Tag-Value AUTHENTICATION_LEVEL=authentication_level

To Test password less login: access the below url
https://myisam/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:mmfa_initiate_simple_login&username=testuser&Target=https://myisam/

Notice that the URL specifies the PolicyId out our "initiate" policy and also provides the user ID of our test user (testuser) in the query string. It also includes a Target parameter which specifies where the user should be sent after successful login.

Select the device that was registered earlier and click Submit.
At this point the Initiate Policy creates an MMFA transaction and displays a "pending" page to the user:

This page is based on a template which can be modified. It includes client-side JavaScript which connects to the transaction status endpoint (via Web Socket) and waits for status updates.
On this page are a set of buttons which trigger actions for the MMFA transaction:
Verify: Polls the authentication service to determine the state of the MMFA process. This can be useful for environments where use of the Web Socket is not possible
Cancel: This cancels the MMFA process. The authentication service returns an error page.
Renotify: This resends the PUSH notification to the authenticator client (asuming PUSH notifications enabled)
Reselect Authenticator: This takes the user back to the device selection page so a different Authenticator client can be chosen to perform the MMFA verification.

now access the verify app in your mobile and click on the sync button (circular button at the top right hand corner) and this is enable a dot on your account...
Select your account now and it will ask for a message saying Please verify login to myisam... click the tick mark and the browser will automatically redirect to the target page...

Now in the above url the target is specified as https://myisam/ this will show be the favicon page...in the same way u can do modifications to you login age to identify here which url the user has requested and reroute that in the browser...
the username is given in the url as testuser...
To change this behaviour u can tweak the authentication policy to accept the username in a request from a html parameter or as a header also...
Now this is the basic method of configuring but this cannot be used in production...we can modify this to a much secure level with some changes to the authentication policy....
We can also add our own javascript to change the way we want this to work...

This method can even be used as a stepup configuration....but will do that all in another post...

For now...thank you and ciao....🙌💃👋

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......

Federated SSO to SalesForce Using ISAM 9

Salesforce is one of the well known applications in the Corporate world and also one of the best applications suited for federation, For all the people who want to learn Federation based SSO, the first example application that you can use to test federation based sso is Salesforce.
Salesforce has one of the best and easy way to configure SAML based SSO functionality.

As a test of ISAM 9 federation capability, i got the chance to integrate salesforce with ISAM 9 VA.
To be honest there were a few issues and being new to the federation capability on VA had to overcome some pretty long hurdles.

After some exploring it feels that IBM has done some pretty good stuff, though it might not have that much flexibilty as TFIM had but overall a good interface to begin with.
and frankly speaking 90% of people dont read the stuff completely, Dont know if anyone is reading this as well ...... :-)

So these are the things that you need to do for configuring SSO to salesforce:

1. Configure TFIM Runtime in ISAM
In the software version, we have to configure runtime manually which creates a application in Websphere. In the VA the runtime comes preconfigured and running as localhost which means its basically using management server ip address.
So first configure a new ip address from interfaces in VA to be specifically used for Runtime,
then go to Secure Federation>> Runtime Parameters,
and in the runtime listening interfaces select the rows with localhost and delete them and configure the same with the new IP which you have configured in interfaces, makes ure to configure with 80 and 443 ports.

2. Create a Mapping Rule using javascript in ISAM mapping rules
This step might seem a little confusing for all the people who were using XSL files for mapping, as the new VA has the support of javascript and not an xsl.
But not to worry as usual if you have the previous version of TFIM installed somewhere make sure to copy the examples folder in it, as it has a lot of information and examples which can help you a lot.
So for the current configuration we will be using your isam userid same as the salesforce userid/emailadress
Go to secure federation>> globalsettings >> mapping rules and add a new rule.
make sure to give the category as SAML2.0
The below image shows the java script that was used for this configuration.
mapping rule image ....

3. Create Federation with the newly created mappping rule.
Go to secure federation >> manage >> federations.
click on ADD button and provide a new name for federation and check the box beside saml 2.0

In Template tab make sure the SAML2.0 checkbox is checked.

Now give a proper name for the company name and also give the provider as https://<websealip>/isam/sps and select the option as identity provider.

Give the point of contact as https://<websealip>/isam

In profile selection, select Web Browser Single sign on.

Single Sign on Settings select the options as shown in the below figure.

In Signature options select as below.

Make sure to select the same certificates as the previous screen.

Keep the settings as shown below.

For Identity Mapping, select the option of javascript transformation for identity mapping.

Select the Identity Mapping which was created previously.

Recheck all your previous selected options in the Summary.

4. verify the TFIM Runtime and get the federation ID.
Now that the Federation is configured we need to confirm the details of the Federation.
Go to Secure Federation >> Global Settings >> user registry.
make sure a user other than admin is created in this example easuser is created.
Now Access the URL in the Browser.
https://<Webseal IP>/Info/InfoServiceXML
For credentials provide easuser and password as passw0rd
This should show you the details of your federation, make sure to note down all the details like federation name, federation ID as well.

5. Configuring Federation(TFIM) with ISAM:
There are multple ways to do this,
We can do the configurations manually(you will learn a lot in this but basically one wrong move can lead to a lot of headache)
Personally i believe the best option to use is  to call the webservice(REST), most people get very afraid of the name webservice but trust me its one of the easiest and most interesting options.
If you have TDI you can use that or curl command or if you have SOAP UI you can use that as well.
The easy option is SOAP UI, which we will be using in this configuration.
So create a REST Project in SOAP UI and provide the details as given in the screenshot.

6. Export the certificate which was used while creating federation for encryption.
In this example we have used the certificate database called rt_profile_keys with a label called server.
Now export this certificate and import it to signer certificates of webseal certificate database in my case it is pdsrv

7. Configure SSO settings in Salesforce and export the metadata.
Login to the sales force application and navigate to Administration Setup -> Security Controls -> Single Sign-On Settings:
and create the SAML 2.0 setup with the below details

8. Use the metadata to create the partner in ISAM.
Now download the metadata from salesforce after configuring sso settings in it.
Now login to ISAM and browse to Secure Federation>> Manage>> Federations.
Then select the federation and click on partners and add a partner.
Now upload the metadata file to ISAM
In the General information tab provide the name as https://saml.salesforce.com as select the check box enabled and click on next.

Give the provider ID as https://saml.salesforce.com and make sure the partner role is selected as service provider and click on next.

select web browser single sign on and click on next.

Keep the settings as default and select next.

In ssl certificates make sure you are using the same certificate as the one that you used in federation and click on Next.

Make sure to have the settings as shown in the below image.

In encryption options select the certificates and click on Next.

In Identity Mapping select the option use Identity Mapping that is configured for this federation.

In summary verify all the options again and click on OK.

This will create your partner and then you are done..

Now access the below url for SSO to salesforce.
https://<your webseal ip/hostname>/isam/sps/salesforce/saml20/logininitial?RequestBinding=HTTPPost&PartnerId=https://saml.salesforce.com&NameIdFormat=email

Assigning Read, Write Permissions to user in IBM TDS

We can assign the permissions to a user using IDSWebApp Console.

Below are the steps to give permissions for a user to login to ldap and perform activities:

1. Go to Directory management => Manage entries.  Select the suffix dc=com and click on Edit ACL.

2. On the left, click on the Non-filtered ACLs. Select the Propagate ACLs check box to allow descendants without an explicitly defined ACL to inherit from this entry. Enter the distinguished name of the lookup user ( like uid=testuser,ou=users,ou=mycom,dc=com)

3. For Type, select access-id, because this DN is a user, then select ADD

4. Assign required Permissions like grant to the Read, Write, Search, and Compare security classes.  Click OK, then OK again on the following screen to save your changes. 

Now you are good to connect to LDAP using the 

Configuring ISIM as a Log Source For Qradar

Simple steps on Configuring ISIM as a Log Source for Qradar:

 For configuring ISIM as a Log Source we have to create two log sources:
1. For Connecting to ISIM DB (All Transactions performed on ISIM)
2. For Getting the ISIM DB Audit Logs(Transactions Performed on the ISIM DB).


ISIM Based Event Configuration:

Network Related configurations:

1. Make sure the DB2 port is open to the Qradar Machine


Configurations on Qradar:

1. Create a Log source for ISIM in Qradar.
2. Provide the below values for the Log source.
Log source Name: (Provide a Name for the Log source)
Log Source Description: (Provide a Description of the Log source)
Log souce Type: Select the option IBM Security Identity Manager.
Protocol Type: IBM Security identity manager JDBC
Log Source Identifier: (Name of DB)@(ip/Hostname of the DB machine)
DataBase Type : DB2
Database Name : (Name of the ISIM DB)
IP or Hostname: (IP/Hostname of the Database)
Port : (Port of DB2)
User name : (Provide the user name for connecting to Qradar)
Password : (Provide the password for the Username used to connect to DB)
Confirm Password : (Provide the password for the Username used to connect to DB)
Table Name : ISIMDB.AUDIT_EVENT
Select List : *
Compare Field : TIMESTAMP
Start Date: (Provide a Start date for the Qradar to read the events from DB, format is yyyy-mm-dd hh:mm)
Polling Interval : 30
EPS Throttle : 1000
Enabled : Check the box
Credibility : 5
Target Event Collector : (Select the first option in the dropdown, Mostly only one option is available)
Coaliscing Events : Check th box
Store Event Payload : Check the box
Log Source Extension : Leave as it is
Extension Use Condition : Leave as it is

3. Save the Log source.

Configuring ISIM Audit Events in Qradar:

Network Based Configurations:
1. Make sure port 22 for ftp/SFTP is open for Qradar to fetch the audit log file.

ISIM DB Based Configurations:

1. Login to DB2 server and switch user to DB instance owner
2. Run below command to configure a path for audit logs
  db2audit configure datapath /data/itimdb/sqllib/security/auditdata/
3. Connect to DB
   db2 connect to isimdb
4. Create audit policy on the database with category ‘execute’ to pick SQL statements executed
   db2 create audit policy db_policy categories execute with data status both error type audit
db2 audit database using policy db_policy
 db2 commit
5. Restart db2audit utility
  db2audit stop
 db2audit start
6. Execute below command to flush out audit log
 db2audit flush
7. Extract the audit logs
db2audit archive database itimdb
8. Extract the logs to a readable format
 db2audit extract from files <filename generated in step 7>
9. Create a Cronjob for the steps from 6 to 8 to be executed every one hour for the audit log to be generated.

Qradar side configurations:

1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for the log source.
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select IBM DB2.
8. From the Protocol Configuration list, select Log File.
9. Provide the values as below:
Log Source Identifier : (IP/ Hostname of the DB2 Machine)
Service Type : FTP/SCP
Remote IP or Hostname : (IP/Hostname of DB2 machine)
Remote Port : 22
Remote User : Username of the user to connect to the db2 machine
Remote Password : Password of the user for connecting to db2 machine
Confirm Password : Password of the user for connecting to db2 machine
SSH Key file : (Only if you are using sftp if not leave it blank)
Remote Directory : Path of the directory in db2 machine where the log file is present
Recursive : (Only if you are using sftp if not leave it blank)
FTP File Pattern : .*.log
FTP Transfer Mode : ASCII
Start time : 12:10
Recurrence : 1H
Run On Save : check the box
EPS Throttle : 100
Processor : From the list, select None.
Ignore Previously Processed File(s): Select this check box
Change Local Directory: Do not select the check box
Event Generator : From the Event Generator list, select LineByLine.

10. Click Save.

TFIM Client certificate renewal

    To avoid criticalities during this activity, it’s advisable to take backups of the keystore.

• Take the backup of both key.p12 and trust.p12 from the location as mentioned below :
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/*******Cell01
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/*******Cell01/nodes/*******Node01
• Get the required certificate(signaturevalidation and encryption certs) for renewal in .PEM format (Only this format).  Certificate can be copied from Metadata file provided by partner. Copy the certificate in the notepad and add Begin and end certificate tags in Beginning and End and save the file in .cer format.
• Import both the certs in DefaultTrustedKeyStore in TFIM (testonly is the password for DefaultTrustedKeyStore).
• Load the Configuration in TFIM.
• Choose the required partner and click on properties.
• Under Signature Validation key, choose keystore >DefaultTrustedKeyStore, provide password and select the signature_validation.crt.
• Under Encryption Key Identifier, choose keystore >DefaultTrustedKeyStore, provide password and select the encryption.crt.
• No changes required under Server Validation Certificate
• Load the Configuration.
• Validate the changes
• Check the partner status(should be enabled) before testing the federation.
• Restart WAS if federation fails to work.(Not Mandatory)
 
  Thanks,
  Nandavaram Pavan Kumar

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

Simple Steps to customize TFIM (Software version) error pages

It is essential to customize the TFIM error pages after configuring Federation to display custom error pages to end user

Below are the simple steps to customize it.

Customize required TFIM error pages as per the requirement (Deafult location of the Webpages: /opt/IBM/FIM/pages/C/saml20) and publish the pages from WAS console to take into effect.


Steps to publish

• Log into the WAS Application Server Console
• Select the Tivoli Federated Identity Manager section
• Select the Domain Management
• Click the Publish pages button
• Click the “Load Configuration Domains “ button.

Now you should see the customized error page

Thanks,
Nandavaram Pavan Kumar

Qradar Integration with IBM SAM for E-Bussiness(VA)

Lately, I been working on the IBM products like ISIG and Qradar and trying to get them integrated with the existing IBM Products like ISIM and ISAM.
ISIG/IGI seems to be a good tool to look upto in future with a strong Workflow system and application integration of ISIM with the Identity/Access Governance features of ISIG it has the capability to become a strong contender for other governance products....
Ok,... Now Leaving all those aside lets look into the Qradar tool..
Qradar is a powerfull tool known across in the IAM World as one of the Strong Monitoring Tools provided by IBM.
So with the IBM trying to promote Virtual Appliance in its IAM World. I thought of trying to integrate Qradar with ISAM for monitoring and naturally with my lack on knowledge on monitoring tools, i came across a few issues while configuring and did not find much help in internet as well...
Except for a great reference from Shane Wheeden(He is like the Hercules in IAM World for IBM Technologies, I mean this guy is everywhere and seems to have done EVERYTHING, "Cheers Mate and may you live longggggggggggg")...

ok So moving on.....

In this integration ISAM VA is configured to send the logs to the Qradar machine on IP 514 and Qradar picks up this logs and provides the event based on the logs.

So if the logs sre sent to Qradar then will the VA do not contain any logs?....
No, The logs will be created in ISAM VA also, The VA will create a seperate instance on logs on the VA apart from the logs being sent to the Qradar and deleting or modifying of these logs do not affect the Qradar instance of log files...

Qradar will read the logs and create the events according to the configuration or the log source extension and based on that it will decode on how to display it in the log events....

Blah blah blah.... and so on and on... Ahhhhhhhh.... Too much explanation.....

Steps to configure ISAM(VA) as a log source with Qradar:

Network Based Configurations:
1. Make sure you have 514 port open from ISAM(VA) to the Qradar(Trust me everyone forgets this).

Qradar Side Configurations:
1. Create a Log Source Extension with the below values.
Name: (Provide a name of your choice)
Description: (Anything that explains why you have this extension created)
Use Condition: Parsing Enhancement
Log Source Type: IBM Tivoli access manager for e-bussiness

2. Now in the Extension Document make sure you type everything that is given below without missing a word or a line.

<?xml version="1.0" encoding="UTF-8"?>
<device-extension xmlns="event_parsing/device_extension">

<pattern id="allEventNames" xmlns=""><![CDATA[(.*)]]></pattern>

<pattern id="RequestLogEventPattern" xmlns=""><![CDATA[<114>1 (.*)]]></pattern>

<pattern id="TimeJan" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-01-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeFeb" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-02-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeMar" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-03-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeApr" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-04-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeMay" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-05-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeJun" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-06-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeJul" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-07-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeAug" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-08-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeSep" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-09-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeOct" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-10-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeNov" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-11-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>
<pattern id="TimeDec" xmlns=""><![CDATA[TS:([0-9][0-9][0-9][0-9])-12-([0-9][0-9])T([0-9][0-9]):([0-9][0-9]):([0-9][0-9])]]></pattern>

<pattern id="UsernamePattern" xmlns=""><![CDATA[ U:(.*) AL:]]></pattern>

<match-group order="1" description="IDaaS Request Log Events" xmlns="">

<matcher field="DeviceTime" order="1" pattern-id="TimeJan" capture-group="Jan \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="2" pattern-id="TimeFeb" capture-group="Feb \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="3" pattern-id="TimeMar" capture-group="Mar \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="4" pattern-id="TimeApr" capture-group="Apr \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="5" pattern-id="TimeMay" capture-group="May \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="6" pattern-id="TimeJun" capture-group="Jun \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="7" pattern-id="TimeJul" capture-group="Jul \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="8" pattern-id="TimeAug" capture-group="Aug \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="9" pattern-id="TimeSep" capture-group="Sep \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="10" pattern-id="TimeOct" capture-group="Oct \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="11" pattern-id="TimeNov" capture-group="Nov \2 \3:\4:\5" enable-substitutions="true"/>
<matcher field="DeviceTime" order="12" pattern-id="TimeDec" capture-group="Dec \2 \3:\4:\5" enable-substitutions="true"/>

<matcher field="EventName" order="1" pattern-id="RequestLogEventPattern" capture-group="Miscellaneous Webseal-Instance Event" enable-substitutions="true" />
<matcher field="UserName" order="1" pattern-id="UsernamePattern" capture-group="1"/>

<event-match-single event-name="Miscellaneous Webseal-Instance Event" device-event-category="Information" send-identity="OverrideAndNeverSend" />

</match-group>

</device-extension>

3. save or submit and then go to the log Souces now..
4. Create a log source with the below values.
Name: (Anything you prefer)
Description: (Anything that explains why you have this extension created)
Log Source Type: Choose IBM tivoli access manager for e-bussiness.
Protocol Configuration: Syslog
Log Source Identifier: ip address of the VA/ Hostname of the VA machine
Enabled: check the box
Credibility: 5
Target Event Collector: eventcollector0 :: qradarisamlog -- (This might change,.. basically you will get only one option so select that)
Do not check the Collascing Event Check box
Incoming Payload Encoding: UTF-8
Store event Paylod : check the box.
Log source Extension: (Provide the name of you extension that you have created previously)
Entension Use Condition: Parsing Enhancement

5. Now save and submit.

ISAM Side Configurations:
To get the events for the Webseal related scenerio's:

1. Edit the configuration file of the Webseal.
In the [aznapi-Configuration] Stanza modify the logcfg parameter as below.

logcfg = audit.azn:rsyslog server="ip/hostname of qradar",port=514,log_id=webseal-websealname
logcfg = audit.authn:rsyslog server="ip/hostname of qradar",port=514,log_id=webseal-websealname
logcfg = http:rsyslog server="ip/hostname of qradar",port=514,log_id=webseal-websealname

To get the Events for the Administration related events for scenerios concering policy server:

1. Edit the ivmgrd configuration file in the Runtime Configuration.
In the [aznapi-Configuration] Stanza modify the logcfg paramter as below.

logcfg = audit.mgmt:rsyslog server="ip/hostname of qradar",port=514,log_id=PDMgrAudit
logcfg = audit.azn:rsyslog server="ip/hostname of qradar",port=514,log_id=PDMgrAudit
logcfg = audit.authn:rsyslog server="ip/hostname of qradar",port=514,log_id=PDMgrAudit


Now you might be wondering if you have multiple webseal what happens then?...
The Qradar gives the events based on the webseal name that you configured so if the log_id is different then the name of the event will have that id as well which will help you in identifying if they are coming from a dfferent webseal.

As there is only policy server so it will give you all the events related to the administration tasks done for other webseals also.. Basically alll the senerios being undertaken in policy server will be recorded in Qradar as an event(Like ACL, POP and User creation)... Even the login to the WPM also..

Note: Do not miss any steps as all the steps mentioned above are mandatory...  :-)