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

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

Cannot Access WebSEAL after applying the ISAM Fix Pack or Updates in Virtual Appliance

Yes this issue occurs in most of the cases when you are upgrading ISAM VA.

Unfortunately most of the interfaces does not communicate or get unresponsive.
Sometimes there are even cases where ISAM users are deleted after applying fixpack but that is a different issue

It is recommended to LDAP and DB2 data backup before applying a update or a fix pack.
On ISAM it is better to take a VM Level Snapshot.
The ISAM VA provides an option for taking snapshot from the ISAM console but it only takes a snapshot of the ISAM configurations and if by any chance your users are deleted it is very hard to restore them back.

When configuring interfaces on an ISAM 8.0.0.x appliance, it is advisable to not
configure IP addresses which reside in the same subnet across multiple interfaces.

Request packets might arrive over a particular interface/IP address, but possibly be returned over a different interface/IP address. In certain environments this proves to be a problem because switches can reject response packets which are returned over a different IP address.

Configuring the same subnet on multiple interfaces will result in the routing table
containing duplicate routes, one for each interface.

This may be the problem if some interfaces seem to become unresponsive or when the packet trace seems to capture traffic only on one side.

There are a couple of ways to address this problem:

Recommended method:

The recommended way to rectify this problem is to configure different interfaces to
be in different subnets. For example, changing the P.1 interface to a different subnet such as 192.168.20.250 / 24 will create distinct routing table entries:

192.168.20.170 - 0.0.0.0 - 255.255.255.0 - P1
192.168.30.170 - 0.0.0.0 - 255.255.255.0 - M1


Alternate method:

Starting with ISAM 8.0.0.5, reverse proxy instances have the capability of listening
on all interfaces and need not be tied to a specific application interface. This means
it is no longer mandatory to configure application interfaces on the appliance.

Note:

This approach is not advisable if the ISAM appliance is being installed in the DMZ.
Since the management interface and any reverse proxy instances would be sharing
the same IP address, management services could possibly end up being exposed to
the public.

a. During configuration of a new reverse proxy instance, specifying 0.0.0.0 for
the IP address of the primary interface ensures that the new instance listens
on all the interfaces including the management interface M.1



b. For existing reverse proxy instances, the primary interface can be changed by
selecting the instance -> Edit and modifying the values on the first tab
'Server'.



Note:

When changing the network interface on which an existing reverse proxy
instance is listening, ensure that no other services are listening on the ports
specified under 'HTTPS Port' and 'HTTP Port'. Otherwise the reverse proxy
instance will fail to start.

By default, ports 80 ad 443 on the management interface are used by the
LMI. If a reverse proxy instance needs to listen on those ports you can
change the default port values used by the LMI using these advanced tuning
parameters:


For Reference:
http://www-01.ibm.com/support/docview.wss?uid=swg21691208

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.

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

How to customize the login page of WebSEAL to render the images properly

Customizing the login.html pages :
1. Open webseal configuration file and search for stanza [content-mime-types] add line as shown below
css = text/css
2. Go to webseal docs directory (Eg :/opt/pdweb/www-webseald/docs/) and place all the css, image files or folders.
3. Change the permission of the folder to 750 (Eg: chmod 750 icons)
4. Change the permission of the images and css file to 440 (Eg: chmod -R 440 * or chmod 440 * r chmod 440 icon-phone-red.png)
5. Change the owner name of all the folders of images and css to ivmgr (Eg: chown ivmgr:ivmgr * )
6. Customize the page as required
7. login to pdadmin
8. Attach unauth ACL to the folders or images (Eg : acl attach /WebSEAL/myssoenv-webseald/_CSS unauth)
Note : Steps 3, 4, and 5 required only if WebSEAL is installed on linux or AIX servers.

By
Nandavaram Pavan Kumar

How to Configure extended attributes in WebSEAL

Steps to Configure extended attributes

1 Login to WebSEAL server.
2 Open the WebSEAL instance configuration file.
Location: /web/pdweb/etc/webseald-<instance-name>.conf
3 In the [aznapi-entitlement-services] stanza, add the property
ISAM_CRED_ATTRS_IDS = azn_ent_cred_attrs
4 In the [aznapi-configuration] stanza, add the property
cred-attribute-entitlement-services= ISAM_CRED_ATTRS_IDS
5 At the end of the file, add the following lines of properties

[ISAM_CRED_ATTRS_IDS]
user = azn_cred_registry_id
[ISAM_CRED_ATTRS_IDS:user]
tagvalue_credattrs_givenname = givenname
tagvalue_credattrs_sn = sn
tagvalue_credattrs_uid = uid


Run the below commands to set the extended attributes at the junction level

pdadmin sec_master> object list /WebSEAL
pdadmin sec_master> object modify /WebSEAL/myssoenv-mywebinst1/MyJct set attribute HTTP-Tag-Value credattrs_uid=SM_USER
or
pdadmin sec_master> object modify /WebSEAL/myssoenv-mywebinst1/MyJct set attribute HTTP-Tag-Value credattrs_uid=uid
pdadmin sec_master> object modify /WebSEAL/myssoenv-mywebinst1/MyJct set attribute HTTP-Tag-Value credattrs_sn=sn
pdadmin sec_master> object show /WebSEAL/myssoenv-mywebinst1/MyJct                                                

Where MyJct is my Junction name

By

Nandavaram Pavan Kumar

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.