Main Page > Liberty Sample Page
Liberty Samples File
This sample includes two Service Providers and two Identity Providers.
This sample demonstrates the different Liberty protocols such as Account
Federation, Single Sign On, Single Logout and Federation Termination.
This sample scenario requires only one Identity Server installation.
Four hosted providers (two Service Providers and two Identity Providers)
are created on the same Identity Server Installation. Each hosted provider
requires a virtual server instance. You need to host the same IP address
(on which the Identity Server is installed) in four different DNS domains.
This can be simulated by adding entries in the /etc/hosts file for the fully
qualified host names of the virtual servers.
Since there are multiple IDPs, you also need to install a common
domain service. This service will be installed with the Identity Server
default installation. You may choose to install it separately on a different
machine. This sample assumes on the same machine.
SP1 and SP2 are two Service Providers. IDP1
and IDP2 are two Identity Providers.
Note:
- For Solaris
<begin_dir> = <IS_Root>/SUNWam
- For Windows2000
<begin_dir> = <IS_Root>/SunONEIS
<begin_dir>/samples/liberty/sample3/
will be referred to as <sample3_dir> .
A. Create and configure sub organizations:
For this sample you will need to create four sub organizations under
the root organization. Each hosted provider will be associated with one
of these sub organizations. The subOrgRequests.xml available
under <sample3_dir> will do the following:
- Create four sub organizations namely
sp1 , sp2 ,
idp1 and idp2 .
- Register Core service and LDAP service for each of these
sub organizations.
- Create service template for the registered services.
- Create a sample user for each of these sub organizations.
These sample users will be created with user
ids as sp1User ,
sp2User , idp1User and idp2User
for the sub organizations sp1 , sp2 , idp1
and idp2 respectively. All the passwords are the same as the
user ids (i.e. sp1User 's password is sp1User ).
- Update the
subOrgRequests.xml (available in <sample3_dir>)
The following assumptions are made in this XML file.
- Identity Server's root suffix is
"dc=example,dc=com"
(attribute "DN" for elements "OrganizationRequests"
and "PeopleContainerRequests" )
- Identity Server (IS) is running in HTTP mode.
- IS is running on port 58080
- IS services are deployed under the URI:
amserver
- The four virtual servers fully qualified host names
are
www.sp1.com , www.sp2.com , www.idp1.com
and www.idp2.com .
Update the above values in subOrgRequests.xml as your
deployment requirement.
- Load
subOrgRequests.xml using the following
command.
<begin_dir>/bin/amadmin -u amadmin -w <amadmin's password> -t <path>/subOrgRequests.xml
B. Upload the meta data:
This sample scenario requires four hosted providers. The metaData.xml
available under <sample3_dir> creates these hosted providers
and configures the meta data for all the providers.
- Update the
metaData.xml (available in <sample3_dir> )
The following assumptions are made in this xml file.
- Identity Server's root suffix is
"dc=example,dc=com"
(attribute "DN" for elements "OrganizationRequests" )
- Identity Server(IS) is running in HTTP mode.
- IS is running on port 58080
- IS services are deployed under URI :
amserver
- Four virtual servers fully qualified host names are
www.sp1.com , www.sp2.com , www.idp1.com
and www.idp2.com .
SP1 Certificate Alias is SP1_SECURITY_KEY
SP2 Certificate Alias is SP2_SECURITY_KEY
IDP1 Certificate Alias is IDP1_SECURITY_KEY
IDP2 Certificate Alias is IDP2_SECURITY_KEY
SP1 metaAlias is www.sp1.com
SP2 metaAlias is www.sp2.com
IDP1 metaAlias is www.idp1.com
IDP2 metaAlias is www.idp2.com
SP1 's associated organization is "o=sp1,dc=example,dc=com" .
SP2 's associated organization is "o=sp2,dc=example,dc=coma ".
IDP1 's associated organization is "o=idp1,dc=example,dc=com" .
IDP2 's associated organization is "o=idp2,dc=example,dc=com" .
- Common domain service is installed on
"http://www.sp1.com :58080/amcommon/"
(If it is installed on a different machine, default port number will
be 80)
Update the above values in the metaData.xml as
your deployment scenario.
Note: In the given metaData.xml common domain
URL's host name is entered as virtual host name (www.sp1.com ),
in this case in FSIntroConfig.properties (available
in <begin_dir>/web-apps/introduction/WEB-INF/classes )
you need to change the cookie domain value to ".sp1.com" .
For example set is as following :
com.sun.identity.federation.services.introduction.cookiedomain=.sp1.com
Alternatively use the original host name in the common domain
URLs so that you need not change the cookie domain value (it will be
set for the original host)
- Load the
metaData.xml using following command.
<begin_dir>/bin/amadmin -u amadmin -w <amadmin's password> -t <path>/metaData.xml
C. Create SP1 virtual server and Deploy SP1:
This sample scenario requires four virtual servers. Urlhosts
for these virtual servers will be assumed as www.sp1.com ,
www.sp2.com , www.idp1.com and www.idp2.com .
- Update
SP1Config.properties (available in <sp3_sample_dir> /sp1/WEB-INF/classes/ )
The following assumptions are made in this xml file.
- Fully qualified host name for the
SP1 virtual
server is www.sp1.com
- Identity Server (IS) is running in HTTP mode.
- IS is running on port 58080
- IS services are deployed under URI -
amserver
SP1 metaAlias is www.sp1.com
Update the above values in the SP1Config.properties
as per your deployment scenario.
- Repate 1 for SP2, IDP1 and IDP2.
- Login to web server as administrator.
- Click <Manage> button to Manage server
(In this case, it is https-<fullhostname>).
- Click on Virtual Server Class.
- Click on Manage for the "vsclass1"
- Click Add Virtual Server
- Name the "Name" to sp1VS
- Select connections(In this case it is the default one)
- Add urlhosts entry to the domain for which the virtual server
runs on. For sp1VS use www.sp1.com
- Add Documentroot entry to <IS_ROOT>/SUNWam/web-apps
- Click OK
- Repeat 6-10 for SP2, IDP1 and IDP2.
- Click Apply and Click Apply Changes. The server will be
restarted.
- Click Virtual Servers and Click Manage (In this case, it is https-<fullhostname>)
- Click Web Applications
- On Server machine, create war file for
SP1
cd <sp1_sample_dir/sp1> jar -cvf sp1.war .
- War File On - Choose Server Machine and click Go
- War File Path - Enter the full patch that the war file we just
created
- Application
URI - /sp1
- Installation Directory : <IS_ROOT>/SUNWam/web-apps
- Repeat 15-19 for SP2, IDP1, IDP2
- Retsart Web Server
D. Configure Identity Server for SP1 virtual server:
- Login to the Identity Server as amadmin and go to the Service
Configuration tab.
- Click on Platform service.
- Add new server as "server with new domain and port". For
example add a value in server list with
"http://www.sp1.com:58080|02"
- Update the cookie domains list in the platform services
with the domain that you have created for the
SP1 - ".sp1.com" .
Add ".sp1.com" to the cookie domains list.
- Add
fqdnMap entry for SP1 virtual
server in /etc/opt/SUNWam/config/AMConfig.properties :
com.sun.identity.server.fqdnMap[www.sp1.com]=www.sp1.com
The FQDN Map is a simple map that enables Identity
Server Authentication service to take corrective action in the case where
the users may have typed in an incorrect URL such as by specifying partial
hostname or using an IP address to access protected resources. This property
can be used for creating a mapping for more than one hostnames. This
may be the case when the applications hosted on this server are accessible
by more than one hostnames.
- Repeat step 1-5 to configure the Identity Server for the
remaining providers (
SP2 , IDP1 and IDP2 ).
Use sp2/idp1/idp2 for all the references to sp1
for the respective provider.
- Restart the web server and the Identity Server.
E. Federate user account at SP1 with an account at
IDP1 :
- Access the following url in a web browser
SERVER_PROTO://SERVER_HOST:SERVER_PORT/sp1/index.jsp
This index.jsp has following three links :
- Federate - will initiate the federation process.
- Logout - will initiate the single logout process.
- Terminate Federation - will initiate the federation
termination process.
Here index.jsp is a protected page which includes
_head.jsp . The _head.jsp will check for valid
user session and if session is invalid it will redirect to preLogin
service. The preLogin service will try to do Single Sign On,
since it is a first time access, Single Sign On will fail and the
preLogin service will redirect to the common login
page.
- On the common login page click on "Local Login" link, you
will be redirected to the
SP1 's login page.
- After successful authentication at
SP1 , you
will be redirected to the index.jsp where you can choose Federate/Logout/Terminate
Federation.
- If you choose to federate, you will be taken to the Federate
page where you can select your preferred Identity Provider to federate
with. Select
IDP1 as the preferred Identity Provider.
- Now you will be taken to
IDP1 's login page
where you need to provide authentication credentials (user-id/password)
for the IDP1 account (in this case idp1User/idp1User ).
If the authentication is successful, you will be shown the FederationDone
page.
- At this point you have successfully federated your account
between
SP1 and IDP1 .
Note: When an account is already federated, the you will be
redirected to the IDP1 Login page first, assuming the common
domain service is properly configured. If the common domain service is
not configured properly then you will see the commonLogin page
where you can click on the IDP1 's link with which you have
federated your SP1 account.
- Repeat step 1-6 to federate your
SP2 account
(sp2User ) with the IDP1 account (idp1User ).
F. Single Sign On:
- After successful federation start a new browser session and
try to access
SP1 protected page (index.jsp ):
SERVER_PROTO://SERVER_HOST:SERVER_PORT/sp1/index.jsp
For example
http://www.sp1.com :58080/sp1/index.jsp
Note: If the earlier session is still valid in the new browser,
then single logout should be done first. See section H for this.
- Now you will be taken to
IDP1 's login page
(Again assuming that the common domain is configured properly). You need
to provide authentication credentials for the user account at IDP1 .
If authentication is successful you will be directly taken to the initially
accessed SP1 protected page without being asked for SP1
authentication credentials.
- Now in the same browser try to access
SP2 's
protected page (http://www.sp2.com:58080/sp2/index.jsp ),
you will be allowed to access this protected page without being asked
for authentication at SP2 (Assuming that you have federated
your SP2 account with the account at IDP1 ).
Again, if common domain is not configured you will see commonLogin
page where you can select a preferred IDP , with which you
federated your account. After clicking on the IDP 's link
you will be able to see the SP2 's initially accessed protected
page.
- Similarly you can demonstrate federation and single sign
on with an account at
IDP2 by repeating all the steps in section
F and section G by selecting IDP2 as the preferred IDP .
G. Single Logout:
- On
SP1 's protected page (index.jsp )
click on "Logout" link.
- You will be logged out from all the valid sessions (in
this case
SP1 , SP2 and IDP1 )s and
will be shown a LogoutDone page.
- Alternatively, you can start the logout process from the
IDP protected page (index.jsp ) as
well and accomplish the same.
H. Federation Termination:
- On the
SP1 's protected page (index.jsp )
click on "Terminate Federation" link.
- You will be taken to a page where you can select a provider
to terminate the federation. For example select
IDP1 for federation
termination.
- On successful federation termination you will be taken to
TerminationDone page.
- Alternatively, you can initiate federation termination from
the
IDP side also and get the same result.
|