Maintaining Logins and passwords

This section covers the following topics:

Changing the super admin password

To change the default admin password, log in to the management console with admin/admin credentials and use the "Change my password" option. After changing the password, do the following:

Change the following elements in <APIM_HOME>/repository/conf/api-manager.xml file:

<AuthManager>
   <Username>admin</Username>
   <Password>newpassword</Password>
</AuthManager>

<APIGateway>
   <Username>admin</Username>
   <Password>newpassword</Password>
</APIGateway>

<APIKeyManager>
   <Username>admin</Username>
   <Password>newpassword</Password>
</APIKeyManager>

Go to the Resources -> Browse menu in the management console to open the registry and update the credentials in /_system/governance/apimgt/applicationdata/sign-up-config.xml registry location.

Do you have any special characters in passwords?

If you specify passwords inside XML files, take care when giving special characters in the user names and passwords. According to XML specification (http://www.w3.org/TR/xml/), some special characters can disrupt the configuration. For example, the ampersand character (&) must not appear in the literal form in XML files. It can cause a Java Null Pointer exception. You must wrap it with CDATA (http://www.w3schools.com/xml/xml_cdata.asp) as shown below or remove the character:

<Password>
    <![CDATA[xnvYh?@VHAkc?qZ%Jv855&A4a,%M8B@h]]>
</Password>

Recovering a password

See How can I recover the admin password used to log in to the management console?

Logging in via multiple user store attributes

See Authentication using Attributes in the WSO2 IS documentation.

Setting up primary and secondary logins

In a standalone deployment of the API Manager instance, users of the API Store can have a secondary login name in addition to the primary login name. This gives the user flexibility to provide either an email or a user name to log in. You can configure the API Store to treat both login names as belonging to a single user. Users can invoke APIs with the same acces token without having to create a new one for the secondary login.

You can configure this capability using the steps below.

Configure user login under the <OAuth> element in <APIM_HOME>/repository/conf/identity.xml file.
1. Mention your primary and secondary login names. Set the primary attribute of the primary login to true and the primary attribute of the secondary login to false.
2. Primary login doesn't have a ClaimUri. Leave this field empty.
3. Provide the correct ClaimUri value for the secondary login
An example is given below:
```
<OAuth>
    ..... . ....
    <LoginConfig>
        <UserIdLogin primary="true">
             <ClaimUri></ClaimUri>
        </UserIdLogin>
        <EmailLogin primary="false">
             <ClaimUri>http://wso2.org/claims/emailaddress</ClaimUri>
        </EmailLogin>
     </LoginConfig>
</OAuth>
```
In the API Store of a distributed setup, the serverURL element in the <APIM_HOME>/repository/conf/api-manager.xml file should point to the key manager instance's service endpoint. This allows users to connect to the key manager's user store to perform any operations related to API Store such as login, access token generation etc. For example,
```
<AuthManager>
   
   <ServerURL>https://localhost:9444/services/</ServerURL>

   
   <Username>admin</Username> 

   
   <Password>admin</Password>
</AuthManager>
```

Tip: In a distributed setup, the API Store's user store needs to point to the key manager user store.

Tip: Be sure to keep the secondary login name unique to each user.

Setting up an e-mail login

See Email Authentication in the WSO2 IS documentation.

Setting up a social media login

You can auto provision users based on a social network login by integrating the API Manager with WSO2 Identity Server. But, this is not supported in a multi-tenant environment.

In a multi-tenant environment, the system cannot identify the tenant domain in the login request that comes to API Manager's Publisher/Store. Therefore, the service provider is registered as a SaaS application within the super tenant's space. Configuring user provisioning is part of creating the service provider. In order to authenticate the user through a third party identity provider such as a social network login, you must enable identity federation. As the service provider is created in the super tenant's space, the provisioned user is also created within the super tenant's space. As a result, it is not possible to provision the user in the tenant's space.

To overcome this limitation, you can write a custom authenticator to retrieve the tenant domain of the user and write a custom login page where the user can enter the tenant domain, which is then added to the authenticator context. Then, write a custom provisioning handler to provision the user in the tenant domain that maintained in the context.

For information on writing a custom authenticator, see Creating Custom Authenticators in the WSO2 IS documentation.
For information on writing a custom login page, see Customizing Login Pages in the WSO2 IS documentation.