I'm using WSO2 Identity Server 5.10.0 with an Open LDAP as a user store and I want to send a SCIM request to another server whenever a new user is created.
To do that I configured my WSO2 to do Outbound Provisioning, by following the WSO2 documentation.
When I create a new user through the Management Console, a SCIM request is properly sent, which tells me that my Outbound Provisioning configurations are probably correct.
However, when I create a new user by constructing a new object directly on the LDAP, no SCIM request is sent to the other server even though the user is properly created and appears when you go to "List" under "Users and Roles" in WSO2's Management Console.
What could be the cause of this and what can I do about it?
Thanks
This is the expected behavior and it's correct.
When you directly create users in the LDAP, WSO2 is not aware of those user creation events. Since the outbound provisioning is triggered upon a successful user creation event, your observation is expected.
Creating users directly in the LDAP is not recommended. User identities should be managed via WSO2 Identity Server. Otherwise, there could occur more issues (caching and data inconsistency issues) than just a provisioning failure.
Finally, if you want WSO2 to provision the users automatically you should create the users via WSO2 (SCIM or management console). Otherwise, you might have to delegate the outbound provisioning process to whatever the entity that's creating users in the LDAP directly.
Related
I'm currently exploring the (Academic Licensed) Office365 API via oAuth access_tokens and have succeeded in retrieving a simple OneDrive folder list via the SharePoint API using access tokens, as a proof of concept.
But this seems to work only for users that are in the Azure maintenance domain that's NOT SSO enabled to our on-premise ADFS server.
The domain that is SSO enabled to our own ADFS server succesfully gets logged in on acquiring the oAuth code and I get a genuine access_token while trading in this code. But using this access_token to retrieve a simple folder list for the user results in this error instead of a folderlist.
{"error_description":"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}
Wich I can't check since I'm not in control of the Azure Sharepoint server.
Did anyone succeed in using the Office365 API icw SSO enabled domains/users?
You'll struggle with an ADFS setup. Any code I've written relies on managed accounts only (i.e. those accounts with a UPN ending with onmicrosoft.com). Each synchronised user from on-premise will have a matching onmicrosoft.com secondary identifier which you should use instead.
I am trying to protect a Java servlet with OpenAM + J2EE tomcat agent. I got this part working by using embedded OpenDJ of OpenAM.
Now I am trying to authenticate against a LDAP server, so I added a LDAP module instance for OpenAM, but I get "User has no profile in this organization" when I am trying use uid/password of an user from that LDAP store.
I checked OpenAM administration guide on this the description is rather brief. I am wondering if it is even possible to do this without using the data store configured for OpenAM?
The login process in OpenAM is made of two stages:
Verifying credentials based on the authentication chain and individual authentication module configurations
User profile lookup
By configuring the LDAP authentication module you took care of the authentication part, however the profile lookup fails as you haven't configured the user data store (see data stores tab). Having a configured data store allows you to potentially expose additional user details across your deployment (e.g. include user attributes in SAML assertions or map them to HTTP headers with the agent), so in most of the scenarios having a data store configured is necessary.
In case you still don't want to configure a data store, then you can prevent the user profile lookup failure by going to Access Control -> <realm> -> Authentication -> All Core Settings -> User Profile Mode and set it to Ignore.
This is unrelated to authentication but it's related to authorization ... you have to configure appropriate policies ... see OpenAM docs.
Agents will enforce authorization, OpenAM determines if the user has the permission to access a protected resource.
As Bernhard has indicated authentication is only part of the process of granting access to a user. He is referring to using a Policy to control access.
Another method is to check if the authenticated user is a member of the desired group programmatically. This can be useful when you want access control over resources that OpenAM doesn't know about (e.g. specific data).
For example, lets say that you want different groups to have access to different rows in a table in a database. You can retrieve the group information associated with the user and add that to your database query, thus restricting the data returned.
I'm sure that you could do this with OpenAM as well using custom modules to allow the policy to use information in the database as resource, but I've found it is much simpler to perform this fine grained access control in your code, and is in all likelihood significantly faster.
We have this scenario -
Data power is used as authentication, and on successful authentication (using ADFS) It is passing LTPA token to worklight calls
At worklight we are using WASLTPARealm and respective LoginModule
What is happening, worklight is looking whether user is in its registry or not which need integrating AD again at WL.
Is it possible to worklight to use data power as trusted partner and don't look for user in registry?
What we are looking is to avoid calling to AD again and still protecting wl resources...
WAS needs to validate the LTPA token so it needs the user registry (in this case the Active Directory server). One solution would to use trust authentication so WAS trusting the requests coming from DataPower but this means that a TAI (Trust Association Interceptor) has to be implemented (not an easy task).
WAS needs to do authorization of incoming user. What is trying to do is validating the LTPA tokent [this happens without AD], and then trying to authorize the user. This authorization decision has to come from somewhere [either from local file or through LDAP]. It is the other thing that, such authorization may not be coming from LDAP [in most cases AD is not configured to return user as a member of specific group with specific resource rights]. In this case WAS do query user for authorization information, but the query will do nothing but doubly check if user exists in particular registry or not [you are correct that there is no point in checking a user again if the LTPA token is valid because LTPA itself is generated from data which queried/authenticated user in [most probably] the same registry]?
Unfortunately there seems to be no way to avoid it.
Ajitabh
I have set up OpenDS and installed the DSML service in Tomcat.
I can verify that the setup works correctly. However, I cannot authenticate to make changes using the DSML service.
In soapUI, I have prepared a request. I have put the principal and password in the HTTP basic authentication properties of the request.
However, when executing the call, I get the following error message in the response from the service:
The entry o=TestOrgUnit,dc=example,dc=com cannot be added due to insufficient access rights
What is the correct way of specifying the credentials otherwise? Is it something that must be done in the SOAP request message?
This should work as long as the principal is in the form of a DN (of an existing user).
The server should also have access controls setup to allow that users to Add entries.
Insufficient access rights seems to indicate that either the LDAP connection was not authenticated, or the ACI do not allow that user to add to the OpenDS directory.
You might want to check OpenDJ DSML gateway as it offers more capabilities that OpenDS with regards to authentication (including support for LDAPS). The trunk or OpenDJ 2.5.0-Xpress1 have that support.
Kind regards,
Ludovic Poitou
ForgeRock - Product Manager for OpenDJ. http://opendj.forgerock.org/
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.