Controlling our own identity by ourselves
In the physical world, we use different types of techniques to prove our identity on different occasions. For example, we use a driving license, national identity card, or passport to prove our identity to certain parties in different scenarios. In the digital world, we can’t use those paper-based methods to prove our identity. Hence usually we use other ways like passwords, biometrics, or even hardware devices to prove our identity. Even though we can prove our identity using one of the above mechanisms, we don’t have a decentralized identity there. In such scenarios, we have to remember and maintain the passwords(or any other authentication mechanism) and we have to provide our user claims by filling lengthy registration forms. To stay away from those we can use Self-Sovereign Identity(SSID). …
First of all, what is ‘Authentication’? Simply ‘Authentication’ is the process of distinctly identifying a certain entity. As the name implies the Multi-Factor Authentication is to use multiple factors to identify a certain entity.
Those factors can be categorized as ;
The knowledge factor is some hidden information that the user knows. This can be a password, username, answer to a security question, PIN or an address. The user should be responsible for not exposing this information to the outside. …
Conventional identity management deals with two types of accounts. They are ,
User accounts have a limited set of privileges to access different resources. Some examples are online shopping accounts, social media accounts and many more. Those resources are protected using an authentication mechanism such as passwords tokens, biometric method, etc.
Privileged accounts are not merely user accounts, but they provide administrative or specialized levels of access based on higher levels of permissions. These accounts are used in organizations to run the business effectively and maintain sensitive data. …
User on-boarding is a very broad topic, first of all let’s check what’s the wikipedia definition for user on-boarding
User on-boarding is the process of improving a person’s success with a product or service. This term is often used in reference to software products, and it can be done in a manual or automated way.
When a new employee is hired or when an employee is leaving the company, it is a big process to include or exclude him to the organization. I have listed few tasks that need to be carried out when a new employee is hired.
Charon is a greek mythology that wikipedia says,
When it comes with the context WSO2 and SCIM2, Charon is an open source library, which implemented SCIM protocol which is an open standard for Identity Provisioning.
Charon library is made from main 4 component
Summer Release: WSO2 Identity Server is the latest success story of WSO2 Identity and Access Management team. After a marathon effort we are glad to release v5.8.0 with few new features, major improvements and some bug fixes
So far WSO2 Identity Server supported OIDC Session Management as the OIDC logout mechanism. From v5.8.0 onwards it supports for OIDC Backchannel logout as well.
OpenID Connect Backchannel logout is a mechanism by which Relying Party (RP) applications are logged out with logout requests communicated directly between RPs and OpenID Providers (OP) bypassing the User Agent. …
This is the first blog of Provisioning Blog series with WSO2 Identity Server.
User Provisioning is an important aspect of the Identity Federation. In simple terms, user provisioning in IAM is to create, update or delete a user account from the system and manage users by providing them access to the resources.
Provisioning APIs are required to manage users in a remote system. For example, Identity Server can be used to manage users and groups. An organization can have an administrative portal which requires to communicate with the Identity Server to manage the users and groups.
So the provisioning APIs are required to support a centralized user base through an IAM system. …
Usually when objects are no longer used by an application those object should be garbage collected. But if these objects are still referenced, then the garbage collector can not remove these objects from the working memory. Further there are some objects stay in the memory through out the life of the application (Ex: static variables). So such applications consume more and more memory and it leads to OOM issues.
In wso2 I have few experiences analyzing memory leaks in some production systems. The possibility of having memory leaks in a production system is bit high as those systems run longer times without giving restarts. In such cases even if there is a tiny memory leak, it accumulates the leak and at last there can be a significant memory leak. …
How to use Mutual TLS with client id and client secret In wso2 IS 5.5.0
This authenticator has the same architecture as the mutual authenticator, https://docs.wso2.com/display/IS550/Mutual+TLS+for+OAuth+Clients.
The only difference is we need to pass the client secret as an query param in the token request. In order to consume the request we need to follow the steps as below. 1. Verify whether the org.wso2.carbon.identity.oauth2.token.handler.clientauth.tlswithidsecret-1.0.7.jar exists in <IS_Home/repository/components/dropins 2. To enable this feature put following configurations in identity.xml which is located in <IS_HOME>/repository/conf/identity
<EventListener type=”org.wso2.carbon.identity.core.handler.AbstractIdentityHandler” name=”org.wso2.carbon.identity.oauth2.token.handler.clientauth.tlswithidsecret.MutualTLSWithIdSecretAuthenticator” orderId=”200" enable=”true”>
3. In order to get a successful authentication, the certificate which is imported to the client-truststore.jks and the certificate which is available in the token request and the service provider certificate should be equal. If we need to skip the validation of the service provider certificate we need to disable the MandateMutualSSL property as below. …
Usually in OIDC the returning claims will be filtered from the requested scopes that is passed to the server as an query param with the authorization request. When it comes to wso2 IS server, it filters the requested claims both from the requested scopes defined with the authorization request and the requested claims that can be configured in service provider configurations. But if Request Object is associated with the authorization request, then the server will return the essential request object claims if those claims are requested from the scope.
This request object can be either
1. request parameter (Passed by…