IS 2
WSO2 Identity Server Tutorial:
WSO2 Identity Server Tutorial:
IS and Analytics
Índice
Introduction
Use Case
Identity Server installation
Running the image in a container.
Docker commands
Key directories in the Identity Server
Key configuration files
SP, Identity Server and Analytics Configuration
IS Analytics and IS
How to download IS Analytics image
Enable Analytics in WSO2 IS
Configure event publishers
Change the administrator password
Running the servers
Networks in Docker
Service Provider
Download from the repository
Service Provider Configuration
Hostname
Travelocity.properties
Tomcat container
Configuration of the SP in the Identity Server
SP certificate
Registration of the new SP
WSO2 IS Data analysis
Analytics Dashboard
Analysis of general login attempts
Analysis of local login attempts
Analysis of federated access attempts
Session Analysis
Monitoring of authentication operations with alerts
Storing containers in a repo
Compose file
Conclusion
Storing containers in a repo
Compose file
Conclusion
Introduction
On this blog, we will navigate through the Identity Server tool or identity server, through some example or
use case related to real life.
use case related to real life.
We will also learn how the tool responds to the management and security of identities, in addition to showing
the necessary flexibility to display statistical data about the login of Service Providers, information about the
session, federated authentication and many other things.
the necessary flexibility to display statistical data about the login of Service Providers, information about the
session, federated authentication and many other things.
Use Case
We start with the example of a company that wants to manage users and accesses of applications by
internal and external personnel. Many of these applications contain sensitive information that must be
protected, since in each application there are users, roles and permissions.
internal and external personnel. Many of these applications contain sensitive information that must be
protected, since in each application there are users, roles and permissions.
The provisioning of users must be fast, as well as protect the interactions between applications. We must
also consider being able to use a single login system in order not to be repeating the credentials every
time the user wants to use a certain application in the system. Because of this, it is decided to use WSO2
Identity Server.
also consider being able to use a single login system in order not to be repeating the credentials every
time the user wants to use a certain application in the system. Because of this, it is decided to use WSO2
Identity Server.
In addition, the system administrators in the company must configure the analyzes for the WSO2 Identity
Server and thus provide the information requested by the superior administration to monitor the session
and authentication statistics. For this task it is decided to use WSO2 Identity Server Analytics.
Server and thus provide the information requested by the superior administration to monitor the session
and authentication statistics. For this task it is decided to use WSO2 Identity Server Analytics.
Identity Server installation
The idea is to deploy in Docker containers: Tomcat, Identity Server and Identity Server Analytics:
For the installation we will use the WSO2 Docker image repository. This is the uri:
https://hub.docker.com/u/wso2/ or in this other uri: https://docker.wso2.com/
https://hub.docker.com/u/wso2/ or in this other uri: https://docker.wso2.com/
The red box shows the image we need to download. If you press DETAILS on the same line, a brief
description of the IS container will appear.
description of the IS container will appear.
The first red box shows the Tags where the different versions of the Identity Server are saved. To the
right is the docker command that we will use to install the IS image on our computer.
If you press Tags:
right is the docker command that we will use to install the IS image on our computer.
If you press Tags:
The latest version is 5.7.0. Now from the command line we can download the container. You have to do
a pull of the image indicating the version you want to install, in this case the: 5.7.0
a pull of the image indicating the version you want to install, in this case the: 5.7.0
At the end of the download, Docker informs us of the completion of the installation of the new image. The
new image is listed in the following screenshot:
new image is listed in the following screenshot:
Running the image in a container.
Now you can run the image in a container. The command line is shown below:
As shown, the name of the container is indicated by the parameter --name. This other -d run the container
in the background and prints the ID or identifier of the container.
in the background and prints the ID or identifier of the container.
Now we just need to check it in the browser with the uri: https://localhost:9443
Now we have runned WSO2IS in a container, let's move on!
Docker commands
Next we will show the output of some important commands. If you want to start learning Docker, write the
same commands that we are explaining with the WSO2IS container example and seeing its output.
same commands that we are explaining with the WSO2IS container example and seeing its output.
The format you must write is the following:
$docker [options] command
docker ps: shows the containers that are running.
The command shows the identifier of the container, the image it runs, ports mapped with the host, container
name...
name...
docker ps -s: The -s option of the ps command shows the size of the files that are included in the
container, as can be seen in the last column.
container, as can be seen in the last column.
docker exec -it wso2is-570 bash: This is to run a command in a container that is active. -it allows you
to open a command window with the container. wso2is-570 is the name of the container that is running.
bash is the Unix shell.
to open a command window with the container. wso2is-570 is the name of the container that is running.
bash is the Unix shell.
docker inspect wso2/wso2is:5.7.0: It returns information at low level of the IS container. The list is very
long to put on the blog, but do not worry we will analyze it in the following posts of this section!
long to put on the blog, but do not worry we will analyze it in the following posts of this section!
docker port wso2is-570: Displays the port mapping of the container. <Host -> Container>
docker container logs wso2is-570: Search and vi
ew the LOGS of a container.
Yes, there are more commands but we will see them in subsequent chapters, do not be impatient.
Key directories in the Identity Server
If we access inside the container, we can navigate between folders to discover the most important directories
of the tool. As we already know:
of the tool. As we already know:
$docker exec -it wso2is-570 bash
bin: This folder contains all the executable files, including the scripts that are used to start/stop the
application in Linux and Windows environments, for example: wso2server.sh and
application in Linux and Windows environments, for example: wso2server.sh and
wso2server.bat.
dbscripts: a collection of database scripts needed to create the Carbon database and the WSO2 IS-specific
database in a variety of database management systems.
database in a variety of database management systems.
lib: The lib directory contains all the jar files that will be converted into OSGi packages at the start up of the
IS and copied to the Dropins directory.
IS and copied to the Dropins directory.
modules:all host objects that belong to the Jaggery module are declared inside the modules folder in a file
called module.xml.
called module.xml.
repository: the main repository for all types of implementations and Carbon configurations. This includes all
the default services, APIs created, Carbon configurations, etc.
the default services, APIs created, Carbon configurations, etc.
resources: contains additional resources that can be used by WSO2 IS.
tmp: It will contain temporary files that are created when a product is running. These files will be deleted
from time to time depending on the maintenance tasks.
from time to time depending on the maintenance tasks.
Key configuration files
<IS_HOME>/repository/conf/carbon.xml
This file is the carbon server configuration file. We can configure for example, the name of the product and
the version, the name Host where the IS server is running, the ports used, information about the internal
LDAP, and many more details that we will expand later.
the version, the name Host where the IS server is running, the ports used, information about the internal
LDAP, and many more details that we will expand later.
<IS_HOME>/repository/conf/datasources/master_datasources.xml
This is where the data sources are configured, that is, where the data sources that store the IS tables are
stored.
stored.
<IS_HOME>/repository/conf/identity/identity.xml
This file configures identity management and protection, with protocols such as OpenID, OAuth, SAML2
Grant type, OpenIDConnect, Multi-factor Authentication, SSO service, rights configuration, SCIM
Authenticators.
Grant type, OpenIDConnect, Multi-factor Authentication, SSO service, rights configuration, SCIM
Authenticators.
<IS_HOME>/repository/conf/log4j.properties
The configuration file of the log4java tool used by the server to generate traces during the operation of the
tool.
tool.
<IS_HOME>/repository/conf/registry.xml
With this file the internal record is configured. This record is used as if it were a directory of folders to store
resources, such as files.
resources, such as files.
These resources can be cached in memory, can be protected in read-only mode, can implement resource
managers. It is also possible to use remote registers, a database where the information of this component
and its resources are stored.
managers. It is also possible to use remote registers, a database where the information of this component
and its resources are stored.
<IS_HOME>/repository/conf/user-mgt.xml
The configuration of the user manager is done in this file: user name, role and password of the administrator,
store where the administrator user resides, configuration of the user store manager and authorization
management.
store where the administrator user resides, configuration of the user store manager and authorization
management.
<IS_HOME>/repository/conf/security/secret-conf.properties
The configuration of the secret administrator that uses the Secret Vault component. The keystore and the
secret repository (Vault) can be configured through this file. All passwords in the tool's xml configuration files
are made secure by protecting them using encrypted text. When a password is encrypted, a keystore is
required to create the decryption cryptography to resolve the encrypted secret values. For this we will use
the secret-conf.properties file.
secret repository (Vault) can be configured through this file. All passwords in the tool's xml configuration files
are made secure by protecting them using encrypted text. When a password is encrypted, a keystore is
required to create the decryption cryptography to resolve the encrypted secret values. For this we will use
the secret-conf.properties file.
SP, Identity Server and Analytics Configuration
In this demo, we will download the image of the IS Analytics and connect it to the IS. This is all we will do:
As you can see in the graph, all the authentication actions generated by the Service Provider (Travelocity)
will be traced by the Identity Server. The data collected through events will be sent to Identity Analytics to
save and display them in a graphical way.
will be traced by the Identity Server. The data collected through events will be sent to Identity Analytics to
save and display them in a graphical way.
IS Analytics and IS
1. How to download IS Analytics image
Now, press DETAILS button, as shown in the image.
For the download, you have to use the command line that shows the red box:
$ docker pull wso2/wso2is-analytics
We will use the latest version, that is exposed in the option: Tags that shows the red arrow. If we click on
those letters:
those letters:
In the red box appears the latest version: 5.6.0. Therefore, the command line to download the image
would be as follows:
would be as follows:
$ docker pull wso2/wso2is-ana:5.6.0
As always you must first try to login to download from the Docker hub:
Now download the image:
It is already ready in the local repository:
2. Enable Analytics in WSO2 IS
To enable the publication of events we must get into the IS container as root to be able to do modifications:
$docker exec -u 0 -it wso2is-570 /bin/bash
And we open the file in edit mode:
<IS_HOME>/repository/conf/identity/identity.xml
- Enable the listener: AuthnDataPublisherProxy
This is the common event detector for all types of analysis supported in WSO2 IS.
This listener captures all the statistics sent to WSO2 IS Analytics as events, and redirects them to the
relevant listener according to their type. This is necessary to enable both session and login analysis.
relevant listener according to their type. This is necessary to enable both session and login analysis.
- Enable the listener: DASLoginDataPublisherImpl
Enable this listener only if you want to analyze statistics related to logins through WSO2 IS.
- Enable the listener: DASSessionDataPublisherImpl
If you want to analyze statistics for specific sessions in WSO2 IS Analytics, this is the listener you should
enable.
enable.
As you can see, whenever you want to enable it you must put the enable parameter, true.
3. Configure event publishers
3. Configure event publishers
All publishers of events related to WSO2 IS Analytics are in the directory:
<IS_HOME>/repository/deployment/server/eventpublishers
Now we will configure the event publishers. To configure the login and session analysis you must use
these files:
these files:
<IS_HOME>/repository/deployment/server/eventpublishers/
IsAnalytics-Publisher-wso2event-AuthenticationData.xml
<IS_HOME>/repository/deployment/server/eventpublishers/
IsAnalytics-Publisher-wso2event-SessionData.xml
Respectively.
- IsAnalytics-Publisher-wso2event-AuthenticationData.xml
receiverURL: It is the final point to which the events are directed from the IS. The format is:
tpc://<HOSTNAME>:<THRIFT_PORT>
or for multiple recipients: {tcp://<HOSTNAME>:<PORT>,tcp://<HOSTNAME>:<PORT>,...}
tpc://<HOSTNAME>:<THRIFT_PORT>
or for multiple recipients: {tcp://<HOSTNAME>:<PORT>,tcp://<HOSTNAME>:<PORT>,...}
Example:
username: This is the user name of the listener.
password: Listener password.
protocol: Protocol used to send/post events.
publishingMode: Asynchronous publication => non-blocking
Synchronous publishing => blocking
publishTimeout: Refers to the wait time for non-blocking publishing mode. Its value is a positive integer.
ssl: Authenticator URL Not included by default. When not included, the authenticator URL is obtained by
adding 100 to the thrift port. The format is: ssl://<HOSTNAME>:<SSL_PORT>.
Example: ssl://localhost:7712
adding 100 to the thrift port. The format is: ssl://<HOSTNAME>:<SSL_PORT>.
Example: ssl://localhost:7712
- IsAnalytics-Publisher-wso2event-SessionData.xml
In our case, the value of receiverURL is the name of the container that runs the IS-Analytics:
wso2is-analytics, that is to say:
wso2is-analytics, that is to say:
4. Change the administrator password
If you want to change the administrator password, write in plain text in the event publishers, parameter:
password. As you can see in the two previous images. Another important fact is that if you have changed
the keystore in the IS Analytics you must import the public key (public certificate) in the IS, in the file:
client-truststore.jks
5. Running the servers
password. As you can see in the two previous images. Another important fact is that if you have changed
the keystore in the IS Analytics you must import the public key (public certificate) in the IS, in the file:
client-truststore.jks
5. Running the servers
If you have made changes to the IS server, you must stop the container and restart it.
To run the IS-Analytics:
$ docker run --name wso2is-analytics -d -p 9444:9444 wso2/wso2is-analytics:5.6.0
We use port 9444 this time because port 9443 is being used by IS. Now in the browser use the uri:
https://localhost:9444/carbon/admin/index.jsp
https://localhost:9444/carbon/admin/index.jsp
And you can check the IS-Analytics in action!
By now we have the two containers running: el IS y el IS-Analytics.
Networks in Docker
When you start a container, what really happens is that in the background you are connected to a
particular Docker network. By default, that is the bridge network.
particular Docker network. By default, that is the bridge network.
Subsequently, each of those networks that you can connect to, routes the requests through a NAT firewall,
which is actually Docker that configures the IP address of the host in its default interface. Thus, your
containers can access the Internet or the rest of your Network to later return.
which is actually Docker that configures the IP address of the host in its default interface. Thus, your
containers can access the Internet or the rest of your Network to later return.
All containers in the same virtual network can communicate with each other without using the parameter:
-p.
-p.
Following good practices, we should create a virtual network for each application and all related. You can
create a virtual network for the Service Provider (Travelocity), the Identity Server with the Identity Server
Analytics. In this way they can talk or connect with each other without problem.
create a virtual network for the Service Provider (Travelocity), the Identity Server with the Identity Server
Analytics. In this way they can talk or connect with each other without problem.
If we visualize the networks configured in Docker:
We see that one of the virtual networks by default is that: bridge.
If we inspect that network we will see the two containers mentioned above.
In the Containers section you can see the names of the two containers and the assigned IP address. The
problem is that each time a container is restarted, Docker can assign a different IP address to it.
problem is that each time a container is restarted, Docker can assign a different IP address to it.
Therefore, it is an antipattern to use the IP of one container to communicate with another. Docker uses the
name of the container, as the equivalent of the Host name, to communicate through the virtual network
different containers, it does so with the DNS daemon. If we use the virtual network by default: default you
have to use the parameter --link to link one container to another so they can communicate without problem,
since in that default network Docker does not use the DNS daemon. We must do this every time the
container is started. One way to avoid this problem is to create a new virtual network, because when
creating a new network, Docker creates that DNS daemon.
name of the container, as the equivalent of the Host name, to communicate through the virtual network
different containers, it does so with the DNS daemon. If we use the virtual network by default: default you
have to use the parameter --link to link one container to another so they can communicate without problem,
since in that default network Docker does not use the DNS daemon. We must do this every time the
container is started. One way to avoid this problem is to create a new virtual network, because when
creating a new network, Docker creates that DNS daemon.
Following the good practices our design, creating a new network, would be as follows:
PVN-SP-IS: Private Virtual Network Service Provider/Identity Server.
For this, we create the new network: $docker network create pvn_sp_is
Now we must connect the IS and the IS-Analytics to the new network:
If we inspect the new network we see that there are two containers:
The virtual networks are connected to the Ethernet interface of the host. Each time a request is sent to:
localhost: 8888 it is routed to the virtual network that contains the listening process on that port, as you
can see in the following image. You have to specify -p for the requests to reach the container connected to
the virtual network.
localhost: 8888 it is routed to the virtual network that contains the listening process on that port, as you
can see in the following image. You have to specify -p for the requests to reach the container connected to
the virtual network.
Now we just need to add the service provider, in our case we have chosen Travelocity.
Service Provider
This service launches the login requests with the SAML protocol to the Identity Server. These actions of
success or failure in the login process will be registered later in the Identity Server Analytics.
success or failure in the login process will be registered later in the Identity Server Analytics.
To do this, first download Travelocity, our Service Provider, configure the connection to the Identity Server
and then configure the new Service Provider in the IS.
and then configure the new Service Provider in the IS.
Download from the repository
First you must create a folder on your system to download the Identity Server examples, with Travelocity
included.
included.
Inside the new folder you have to start the new Git repository. Our folder now has an empty repository in
/.git/ (the repository is a hidden folder where Git operates.)
/.git/ (the repository is a hidden folder where Git operates.)
Now we configure in our local git the repository that we want to download:
$ git remote add -f origin https://github.com/wso2/product-is.git
git-remote - Manage a set of tracked repositories.
add -f - Add the new repository from the source to our folder. With the option -f, git fetch <nombre> it
is executed immediately after configuring the remote information. And the git fetch <name> command can
be used to create and update the remote tracking branches <name>/<branch>.
is executed immediately after configuring the remote information. And the git fetch <name> command can
be used to create and update the remote tracking branches <name>/<branch>.
Enable option sparseCheckout:
It is used to download from the repository only the files we want to use, and not all documents. And it is
now when we tell Git what things we want to download. It is done in the directory /ISSamples/.git/info.
In our case we want to download the folder: modules/samples/
now when we tell Git what things we want to download. It is done in the directory /ISSamples/.git/info.
In our case we want to download the folder: modules/samples/
In the sparse-checkout file, folder or files that we want to download from the repository are written. Now
we go to the folder where we were originally, that is: $ cd ../..
we go to the folder where we were originally, that is: $ cd ../..
Now we download the contents of the repository from the branch: v5.5.0 to another local branch with the
same name.
same name.
As you can see in the image, the folder that we indicated previously was downloaded: modules/samples/.
Our Service Provider example is inside the folder: /modules/samples/sso.
Our Service Provider example is inside the folder: /modules/samples/sso.
Service Provider Configuration
Now we have to configure Travelocity (our Service Provider) to be able to connect to the Identity Server and
be able to send SSO authentication requests through the SAML protocol (Single Sign On - SSO), this is
the single session initiation based on a web browser.
be able to send SSO authentication requests through the SAML protocol (Single Sign On - SSO), this is
the single session initiation based on a web browser.
As we already knew, single sign-on is a key feature of WSO2 Identity Server that allows users to access
multiple applications using the same set of credentials. In addition, the user can access all these
applications, systems and platforms, without having to login individually.
multiple applications using the same set of credentials. In addition, the user can access all these
applications, systems and platforms, without having to login individually.
For example, if users login in to application A, they would automatically have access to application B for the
duration of that session, without having to re-enter their credentials. Later on we will dedicate a post around
this concept for a better understanding.
duration of that session, without having to re-enter their credentials. Later on we will dedicate a post around
this concept for a better understanding.
Hostname
Add the following entry to the /etc/hosts file to configure the hostname on the laptop where the containers are
running:
running:
127.0.0.1 wso2is.local
Some browsers do not allow you to create cookies for a hostname such as localhost. Cookies are required
when working with SSO.
when working with SSO.
Therefore, to ensure that the SSO capabilities work as expected, it is important that we configure this file.
Travelocity.properties
At this moment we must configure the file travelocity.properties.
It is on the path:
/ISSamples/modules/samples/sso/sso-agent-sample/src/main/resources/
It is on the path:
/ISSamples/modules/samples/sso/sso-agent-sample/src/main/resources/
- Configure the following properties with the name of the Tomcat container as the host name:
#The URL of the SAML 2.0 Assertion Consumer
SAML2.AssertionConsumerURL=http://wso2is.local:8888/travelocity.com/home.jsp
#openid.return_to parameter
OpenId.ReturnToURL=http://wso2is.local:8888/travelocity.com/home.jsp
- Configure these other properties and use as host name localhost:
#The URL of the SAML 2.0 Identity Provider
SAML2.IdPURL=https://localhost:9443/samlsso
#OAuth2 token endpoint URL
OAuth2.TokenURL=https://localhost:9443/oauth2/token
#OpenId Provider Url
OpenId.ProviderURL=https://localhost:9443/openid/
#A unique identifier for this SAML 2.0 Service Provider application
SAML2.IdPEntityId=localhost
#The URL of the SAML 2.0 Assertion Consumer
SAML2.AssertionConsumerURL=http://wso2is.local:8888/travelocity.com/home.jsp
#openid.return_to parameter
OpenId.ReturnToURL=http://wso2is.local:8888/travelocity.com/home.jsp
- Configure these other properties and use as host name localhost:
#The URL of the SAML 2.0 Identity Provider
SAML2.IdPURL=https://localhost:9443/samlsso
#OAuth2 token endpoint URL
OAuth2.TokenURL=https://localhost:9443/oauth2/token
#OpenId Provider Url
OpenId.ProviderURL=https://localhost:9443/openid/
#A unique identifier for this SAML 2.0 Service Provider application
SAML2.IdPEntityId=localhost
Now in the terminal, access the folder /modules/samples/sso/sso-agent-sample and compile the
example using the following command: $ mvn clean install
example using the following command: $ mvn clean install
After successfully generating the example, you can find the .war file called travelocity.com within the
directory: /sso/sso-agent-sample/target.
It is time to deploy this war file in a Servlet container, for this, use the Apache Tomcat Servlets container.
Tomcat container
The Service Provider example is written in Servlet 3.0. Therefore, you must run the Tomcat 7.x servlet
container. We will do this by downloading a Tomcat Docker image.
container. We will do this by downloading a Tomcat Docker image.
To do this go to the uri: https://hub.docker.com/r/library/tomcat/ where you can find the Tomcat image
that we will use.
that we will use.
The version that we will install is: 9.0.13. If you click on Tags you can see the list of available versions.
With this command you can pull the image: $ docker pull tomcat:9.0.13
You can check the installation by listing the Docker images:
Next, we must run Tomcat container:
$ docker run -it -p 8888:8080 tomcat:9.0.13
Note:
How to rename a container? $ sudo docker rename old_name new_name
|
First of all you have to configure Tomcat with the user and password to access the console. To do this,
restart the container and enter the console:
restart the container and enter the console:
$ docker container restart tomcat9013
$ docker exec -it tomcat9013 bash
Now you have to configure the file: tomcat-users.xml. For example, these are the users and roles that
we are using:
we are using:
Therefore, to enter the console you must type: tomcat/tomcat as username and password respectively.
Do not forget to restart the container again!
Do not forget to restart the container again!
Note:
If when restarting Tomcat, browser does not show you the login window, look for the file:
CATALINA_HOME/webapps/manager/META-INF/context.xml and add the comments around Valve:  |
In the browser you can now see the Tomcat console.
Finally, do not forget to connect the Tomcat container to the network: pvn_sp_is
Now we have the three containers in execution:
Tomcat, WSO2-IS and WSO2-IS-Analytics:
And all three in the same network:
$ docker network inspect pvn_sp_is
As we saw, depending on the order in which the containers start, they can obtain a different IP address.
That's why we can not refer to them through their IP, but with the name of the container:
wso2is-750, wso2is-analytics, tomcat9013.
The docker DNS daemon matches the name of the container and its IP address.
That's why we can not refer to them through their IP, but with the name of the container:
wso2is-750, wso2is-analytics, tomcat9013.
The docker DNS daemon matches the name of the container and its IP address.
Finally, deploy Travelocity war on the Tomcat. Select: Manager App.
As you can see in the image, you only have to select the war file from the folder and click on Deploy.
In the Applications section you can see the war displayed correctly:
Configuration of the SP in the Identity Server
It's time to configure the service provider in the Identity Server: Travelocity.
To do this you have to access the Identity Server console:
https://localhost:9443/carbon/admin/login.jsp, user and password: admin/admin.
https://localhost:9443/carbon/admin/login.jsp, user and password: admin/admin.
Now select add under the section Service Providers.
In the next screen, we choose manual configuration mode, you can also import an xml file with all
the configuration of the Service Provider.
the configuration of the Service Provider.
Our Service Provider Name is: Travelocity.com. Press: Register.
SP certificate
Now you have to import the Service Provider certificate. In the versions prior to 5.5.0 the certificate was
imported into the KeyStore, from 5.5.0 the certificate is saved in Database, as we are going to do. This
certificate is used to validate the signing of signed requests or requests from the Service Provider in the
Identity Server.
imported into the KeyStore, from 5.5.0 the certificate is saved in Database, as we are going to do. This
certificate is used to validate the signing of signed requests or requests from the Service Provider in the
Identity Server.
In our example they will be SAML2 authentication requests and SAML2 session close. The format of the
certificate is the PEM, encoded in Base64 with ASCII characters. You must now obtain the PEM
certificate from a JKS file (Java KeyStore (JKS) is a repository of security certificates). For this we must
go to the route:
certificate is the PEM, encoded in Base64 with ASCII characters. You must now obtain the PEM
certificate from a JKS file (Java KeyStore (JKS) is a repository of security certificates). For this we must
go to the route:
/modules/samples/sso/sso-agent-sample/src/main/resources
In the red box is the JKS file from which we will extract the certificate. To make the export you must use
this command:
this command:
keytool -export -keystore wso2carbon.jks -alias wso2carbon
-file wso2carbon.crt
-file wso2carbon.crt
The certificate appears in the same folder:
The file contains a certificate encoded in binary. Now we must pass it to PEM format. This is the
command:
command:
openssl x509 -inform der -in wso2carbon.crt -out wso2carbon.pem
As shown in the image, the content of the certificate is ASCII. Now we import that certificate as:
Application Certificate:
Application Certificate:
WSO2 gives us the possibility to import the file or make a copy/paste of the certificate within the frame.
Registration of the new SP
Now you have to go to the section Inbound Authentication Configuration and within it
SAML2 Web SSO Configuration. Click on Configure:
SAML2 Web SSO Configuration. Click on Configure:
In the next screen choose also manual configuration and enter the data as shown in the screen below
and at the end click: Register.
and at the end click: Register.
Issuer: It is the identifier of the Service Provider. This value has to match the one we have configured in:
travelocity.properties within: SAML2.SPEntityId.
travelocity.properties within: SAML2.SPEntityId.
That is to say: travelocity.com
Assertion Consumer URLs: This is the endpoint used by the Identity Provider in the Identity Server to
which the responses to the authentication requests of the Service Provider are redirected. It is the
Assertion Consumer Service (ACS) of the Service Provider. If the request coming from the Service
Provider is signed and contains another ACS URL, the Identity Server will use that other URL as ACS.
The value of this field has to match the one we have put in: travelocity.properties within:
SAML2.AssertionConsumerURL.
which the responses to the authentication requests of the Service Provider are redirected. It is the
Assertion Consumer Service (ACS) of the Service Provider. If the request coming from the Service
Provider is signed and contains another ACS URL, the Identity Server will use that other URL as ACS.
The value of this field has to match the one we have put in: travelocity.properties within:
SAML2.AssertionConsumerURL.
Default Assertion Consumer URL: In this section we can have several Assertion Consumer but we
must select the one we are using in: travelocity.properties.
must select the one we are using in: travelocity.properties.
That is to say: http://wso2is.local:8888/travelocity.com/home.jsp
NameID format: This is the format of the information exchanged between SP and the IS, indicated by
the NameID format (this and other formats are described in the SALM2 specification). In this way both
parties easily identify the format in which they receive the information or the data. In our case, the
information that is exchanged is the 'emailAddress' and the format is:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress.
the NameID format (this and other formats are described in the SALM2 specification). In this way both
parties easily identify the format in which they receive the information or the data. In our case, the
information that is exchanged is the 'emailAddress' and the format is:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress.
Certificate Alias: The certificate, as you know, is used to validate the requests of the Service Provider in
the Identity Server. It is the alias that was used to export the public certificate of the SP. Here is the alias
of the certificate that we are going to use for it. Choose: wso2carbon
the Identity Server. It is the alias that was used to export the public certificate of the SP. Here is the alias
of the certificate that we are going to use for it. Choose: wso2carbon
Response Signing Algorithm: Algorithm (SignatureMethod) used in the signature for the POST binding
is indicated. In our case it is:
is indicated. In our case it is:
Response Digest Algorithm: The algorithm (DigestMethod) used in the signature for POST binding is
indicated. In our case it is: http://www.w3.org/2000/09/xmldsig#sha1
indicated. In our case it is: http://www.w3.org/2000/09/xmldsig#sha1
Assertion Encryption Algorithm: An assertion is an information packet related to the Subject (usually
the end user): http://www.w3.org/2001/04/xmlenc#aes256-cbc
the end user): http://www.w3.org/2001/04/xmlenc#aes256-cbc
Key Encryption Algorithm: Encryption algorithm of the SAML2 key.
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
Enable Response Signing: This is used to sign the returned SAML2 responses after the authentication
process is completed. This option is selected to true.
process is completed. This option is selected to true.
Enable Signature Validation in Authentication Requests and Logout Requests: This indicates whether
the identity provider (IdP) must validate the signature of the SAML2 authentication request and the SAML2
session closure request that is sent by the service provider (SP).
the identity provider (IdP) must validate the signature of the SAML2 authentication request and the SAML2
session closure request that is sent by the service provider (SP).
Enable Assertion Encryption: This option is to encrypt the SAML 2 assertion or not.
Enable Single Logout: All sessions are terminated once the user closes a server session.
SLO Response URL: This is to use an endpoint other than the assertion consumer. This new endpoint
accepts a unique session closing response from the IS.
accepts a unique session closing response from the IS.
SLO Request URL: In this section, it indicates the end point of the SP that the IS uses to send session
closing requests other than the consumer assertion endpoint.
closing requests other than the consumer assertion endpoint.
Enable Attribute Profile: Identity Provider includes the claims selected by the user when configuring the
claims of the Service Provider. They are user attributes that are included in the SAML Assertions.
claims of the Service Provider. They are user attributes that are included in the SAML Assertions.
Enable Audience Restriction: Indicates the response receivers of the SAML assertion. In our example we
do not put anything.
do not put anything.
Enable IdP Initiated SSO: In this case the federated authentication process is initiated when the Identity
Provider sends an unsolicited SAML response to the SP. In our case we leave it unselected.
Provider sends an unsolicited SAML response to the SP. In our case we leave it unselected.
Enable IdP initiated SLO: This option allows the Identity Provider to send SAML2 requests of logout to the
SP. In our case we leave it disabled.
SP. In our case we leave it disabled.
Enable Assertion Query Request Profile: With this option you can send SAML2 assertions requests. We
do not use it in this case.
do not use it in this case.
WSO2 IS Data analysis
WSO2 Identity Server Analytics will allow you to view and analyse statistics related to authentication
requests that pass through WSO2 Identity Server. You can configure WSO2 IS to post events related to
authentication in WSO2 Identity Server Analytics so that you can see and analyse the following:
requests that pass through WSO2 Identity Server. You can configure WSO2 IS to post events related to
authentication in WSO2 Identity Server Analytics so that you can see and analyse the following:
- Logon Analysis: includes statistics related to logon attempts made through WSO2 Identity Server. For security reasons, you can not see the statistics related to the login attempts of the administration console and the grant types, such as the password.
- Session analysis: includes statistics related to specific sessions that are created for different applications that are accessed through WSO2 Identity Server.
We already have everything running in the same virtual network with the SP configured in the IS and
deployed in Tomcat, and the IS connected to the IS-Analytics. It's time to analyse the authentication and
session operations. For this we use the WSO2 IS Analytics Dashboard that presents statistics related to
these activities. But before that we are going to perform some successful and unsuccessful session
actions of example to be able to visualise data in the Dashboard Analytics.
deployed in Tomcat, and the IS connected to the IS-Analytics. It's time to analyse the authentication and
session operations. For this we use the WSO2 IS Analytics Dashboard that presents statistics related to
these activities. But before that we are going to perform some successful and unsuccessful session
actions of example to be able to visualise data in the Dashboard Analytics.
To do this go to Tomcat, start the web application travelocity, as shown by the arrow on the right and
open the application using the link shown on the left in a new tab in the browser.
open the application using the link shown on the left in a new tab in the browser.
If you select the new tab you can see the Service Provider's website:
We are going to use SAML2 authentication, for this we must use the first option of the main menu with
the user/password: admin/admin. After that the browser is redirected to the IS for the authentication
process. If it is satisfactory, the Identity Server redirects the browser to the home of the SP.
the user/password: admin/admin. After that the browser is redirected to the IS for the authentication
process. If it is satisfactory, the Identity Server redirects the browser to the home of the SP.
Press Logout (HTTP Post) to exit the session and return to the SP Index screen. Now repeat the
process but making several failed session attempts.
process but making several failed session attempts.
Analytics Dashboard
To visualise the data we must go to Identity Server Analytics and select Analytics Dashboard:
After that, it shows Dashboard Server, select View within Security Analytics.
The Analysis Panel appears with a summary of general login attempts, local login attempts, and
federated login notifications.
federated login notifications.
At the top you can apply a filter to select the time from where you want to analyze the data: Last Hour,
Last 24 Hours, Last 30 Days, Last Year, or even choose a start and end date in the calendar:
Analysis of general login attempts
If you select See more >> you can see more detailed information about the logins. For example in
Overall Login Attempts when selecting See more >> button this is the screen that appears (or left menu,
option OVERALL):
Overall Login Attempts when selecting See more >> button this is the screen that appears (or left menu,
option OVERALL):
the time in which each of them occurred. The world map allows you to see the countries from which the
session starts were attempted.
session starts were attempted.
In the intermediate gadget appear data related to the Service Provider (which started the login process) and
the attempts both correct and incorrect. On the right there is also an interesting data related to the incorrect
username used in the login, in our example the incorrect user was: sss.
the attempts both correct and incorrect. On the right there is also an interesting data related to the incorrect
username used in the login, in our example the incorrect user was: sss.
displayed where Context ID or session identifier is listed, user name used in the login, the Service Provider
to which the user tries have access, Subject Step, the role of the user, the tenant, IP, region, login process
result, and time in which the process of login attempt was made.
to which the user tries have access, Subject Step, the role of the user, the tenant, IP, region, login process
result, and time in which the process of login attempt was made.
At the top appears a button in blue to export the document in PDF format. A report is generated with this
detail:
detail:
Analysis of local login attempts
A local authentication is an action that is performed through a local identity provider. The statistics shown on
this page include all the local login attempts that are made through local identity providers over time, as well
as the local login attempts filtered according to the service providers, the user stores, the roles of users and
users.
this page include all the local login attempts that are made through local identity providers over time, as well
as the local login attempts filtered according to the service providers, the user stores, the roles of users and
users.
In the image, specifically in the red box, the total number of attempts to start a local session that are
performed during the selected time interval is presented.
performed during the selected time interval is presented.
Below, on the same screen, graphs showing the successful and unsuccessful local login attempts sorted by
the service provider, by domain of the user store, by user role and sorted by user name are displayed:
the service provider, by domain of the user store, by user role and sorted by user name are displayed:
Below is the detail of each attempt to start a local session, also exportable to PDF:
Analysis of federated access attempts
A federated authentication is an authentication activity that is performed through an identity provider external
to the IS.
to the IS.
The statistics shown on this page include all federated login attempts that are made through federated
identity providers over time, as well as local login attempts filtered by service providers, vendors of identity
and users.
identity providers over time, as well as local login attempts filtered by service providers, vendors of identity
and users.
In our example, I have not performed any local-only federated authentication. This type of authentication will
be explained in future posts.
be explained in future posts.
Session Analysis
This screen shows statistics related to the sessions of the different applications for which it is accessed
through WSO2 IS, in our example the application is Travelocity. The upper part of the image shows on
the right the currently active sessions that are updated in real time according to the events that come from
WSO2 IS.
through WSO2 IS, in our example the application is Travelocity. The upper part of the image shows on
the right the currently active sessions that are updated in real time according to the events that come from
WSO2 IS.
On the left, the sessions are displayed over the selected time. In total, active, new and completed sessions
are shown.
are shown.
In the following widgets, the longest sessions that took place during a given time interval for the duration of
the session are presented. In the centre, the average duration of a session based on the most frequent
users for the selected time interval. And at the end on the right the sessions are grouped by duration and
shows the number of sessions for each group during the given time interval.
the session are presented. In the centre, the average duration of a session based on the most frequent
users for the selected time interval. And at the end on the right the sessions are grouped by duration and
shows the number of sessions for each group during the given time interval.
Below there are details of each session including: Name of the user who made the session, the start and
end time of the session (event of closing session or forced termination).
end time of the session (event of closing session or forced termination).
The end time of the session, that is, the time at which the session is supposed to end, the duration of the
session, whether the session is currently active or not, the domain of the user store, the IP address of the
server , the domain of the tenant, if the flag to remember is configured or not, the time stamp. All this
information is exportable to a PDF file:
session, whether the session is currently active or not, the domain of the user store, the IP address of the
server , the domain of the tenant, if the flag to remember is configured or not, the time stamp. All this
information is exportable to a PDF file:
Monitoring of authentication operations with alerts
In this section I summarise a series of configurable alerts in files with siddhi extension:
Suspicious login: A successful login after a certain number of unsuccessful login attempts during a
Suspicious login: A successful login after a certain number of unsuccessful login attempts during a
Long sessions: The duration of the session of a specific user exceeds a predefined duration of time.
All alerts are visible in the options menu on the left, SECURITY ALERTS:
Storing containers in a repo
To store the containers in a repo first of all the container must to be converted to an image:
1) Container: wso2is-analytics
Create a new image from a container's changes:
$docker commit wso2is-analytics
Add a tag to the image:
$docker tag 2b37fb87613b tomasrabazo/wso2is-analytics_5.6.0
Login to the repo:
$docker login
Now push the image:
$docker image push tomasrabazo/wso2is-analytics_5.6.0
The image is in the repo:
$docker tag 2b37fb87613b tomasrabazo/wso2is-analytics_5.6.0
Login to the repo:
$docker login
Now push the image:
$docker image push tomasrabazo/wso2is-analytics_5.6.0
The image is in the repo:
2) Container: wso2is-570
$ docker commit wso2is-570
$ docker tag 175ae5c918d4 tomasrabazo/wso2is-570
$ docker image push tomasrabazo/wso2is-570
3) Container: tomcat9013
$ docker commit tomcat9013
$ docker tag fb393e7b2adc tomasrabazo/tomcat9013
$ docker image push tomasrabazo/tomcat9013
Compose file
Compose file
Once everything is in the repository I have built a composite file to be used to install all three containers
in others laptops:
To execute the file type:
$ docker-compose up -d
To stop and remove containers, networks, images, and volumes:
$ docker-compose down
$ docker-compose up -d
To stop and remove containers, networks, images, and volumes:
$ docker-compose down
Note:
Do not forget to add the following entry to the /etc/hosts file to configure the hostname on the laptop where the
containers are running:
127.0.0.1 wso2is.local
Conclusion
After all the comments, you should know that we have presented one of the most important parts about
the Identity Server, which includes the SSO validation using the SAML 2.0 protocol, with the integration of
the Service Provider with the IS and the transmission of IS events to the IS-Analytics.
This last tool has the ability to show in a configurable way a series of data and reports related to SP-IS the Identity Server, which includes the SSO validation using the SAML 2.0 protocol, with the integration of
the Service Provider with the IS and the transmission of IS events to the IS-Analytics.
interaction that help the company to study and analyse these statistical data to make future decisions. This
functionality of the tool is extensible and adaptable to new patterns defined by the business.
We have also been able to perform this demonstration with Docker containers and virtual networks, allowing functionality of the tool is extensible and adaptable to new patterns defined by the business.
us to see the flexibility and simplicity of Docker tool to be able to visualise any type of pattern that we
want to model, both in the interaction of components and in the creation of virtual networks.
And now we must keep trying playing with the tool and the possible configurations of the alerts, a topic want to model, both in the interaction of components and in the creation of virtual networks.
that did not need to be extended here. But after all the work done so far the reader will find it much easier
to experiment on their part.
In the next chapters on WSO2 Identity Server we will continue to explore in more detail the Identity Server to experiment on their part.
tool and other menu options and security management with other protocols. You are ready? Read us in
the next post.
In case you can not wait for the next one and need advice or help to incorporate WSO2 Identity Server the next post.
in your company, do not hesitate to get in touch with our team.
No comments:
Post a Comment