I'm currently confused by the IDs identifying a user in Connections, and their link to the underlying LDAP directory.
So far, I identified several ids:
email: simple but not reliable as email access might have been disabled by the admin. This is particularly true for Connections cloud.
snx:userid: UUID generated by Connections, but this is the chicken and egg. To find the userid, you need to first get access to a profile document, or some data retrieved from Connections
key: also generated by Connections, but I don't get the pattern. On Greenhouse, it is yet another UUID in x-profile-key, different from the userid above. On other systems, it seems to be based on the user name.
subscriberId: The "lotuslive id" used by Connections cloud.
Can someone explain the relationship between snx:userid, key and subscriberId, on-prem and on the cloud, and what they are for? I can't find any clear documentation around it. The API doc says that some times we should pass the key, and some times the id.
Also is the LDAP directory on prem. We are querying the LDAP directory (WAS federated directory, also used by Connections) to get a list of users based on a group. But then, how can we access their Connections profiles from the LDAP result? Is their an attribute to read? We are currently using the email, but as said earlier, this will not work if email access in disabled, like in Greenhouse.
I can explain part of it. the snx:userid is an abstraction used to uniquely identify a person - even if their email changed, name changed, or any other ldap specific id changed. The snx:userid is I believe 64bit.
I thought the Key is the same as snx:userid.
SubscriberId is based on the Business Support Services long id, and includes a scope so that each environment has a unique id.
I think I described the first part of your question on the relationship.
For the second bit, we don't augment LDAP with the snx:userid.
You may want to look at User SPI and java.lang.String getExtID()
http://www-10.lotus.com/ldd/lcwiki.nsf/xpAPIViewer.xsp?lookupName=IBM+Connections+5.0+API+Documentation#action=openDocument&res_title=User_SPI_ic50&content=apicontent
Hopefully this will help clear up some of the confusion and break down their relationships and uses.
snx:userid — This is actually not “generated” by Connections, but rather is associated with an LDAP attribute that is defined during the population process. Generally it is defaulted to an LDAP attribute that is and will always be unique to a user so that it can be used to identify a user in the LDAP if other content has changed. In some cases you’ll see this as the GUID of the LDAP (the default setting on-prem), though other times you’ll see this as a different value, like on the cloud for example. The cloud has this set this to the subscriberId.
subscriberId — This is generated and based on our Business Support Services as Paul mentioned. It is used as the true unique identified for a “subscriber” (user) to the environment, since the environment is MT and users need to be scoped. This was chosen over the default GUID as a unique identifier for a variety of logistical reasons.
key — This is generated by Connections itself during the population process. It is used to define the users profile within the context of Profiles and provides Connections with the ability to associate content with a user when the users LDAP information has been altered. It provides a separation of identity and helps facilitate user content synchronization for Connections.
Unfortunately there isn't a clear cut way to perform that lookup though, especially when you take something like Connections Cloud or Greenhouse into account. They have email disabled for a variety of security reasons. Generally speaking though, the userId is the GUID for the ldap, unless it is very explicitly redefined and configured so, but again you'd really have to know the environment in order to know that information. In a nutshell I think it has to be a configuration parameter for the app per environment if email is disabled.
Related
I'm learning about Google OAuth, and it says that my project has no appropriate credentials.
So I go to the Developers Console and click on the OAuth consent screen. I type my domain name into their question:
Authorized domains To protect you and your users, Google only allows
applications that authenticate using OAuth to use Authorized Domains.
Your applications' links must be hosted on Authorized Domains.
I have verified my domain, but I get "Must be a top private domain." The link takes me to some kind of java programming statement. Actually if I click on the Domain verification tab (again) there are no domain names listed, but I know I added it.
Q: How do I add my domain for being used with OAuth? Must I qualify it as a Top Private Domain or am I going down a rabbit hole?
Google oauth requires a top level domain for security purposes. A top level domain is the first one before the .com .net .biz, in other words it only has one dot. There are exceptions such as .co.uk.
Subdomains are controlled by the parent domains and are not necessarily owned or controlled by you. Imagine you have a Wordpress account at domain.wordpress.com. Wordpress closes your account and returns domain to inactive. A different user claims the domain user and domain.wordpress.com. If Google allowed subdomains they would be forced to believe the new user was you. (Since there is no requirement of public notification of the change)
Edit (a more generalized statement in response to a comment.)
If you own the domain, you have full control over it, and the ownership records are public. To prove your virtual identity as owner of the domain when subscribing to many services require a DNS record, that is created by you, as a challenge created by the provider, that can be read by the provider, prior to services being created. In the event of a change in ownership the original claimant, you, is sent a new record to the provided email address to add to your DNS server to prove you still own the domain. If you cannot prove you still maintain ownership of the name, as in the case of an expired domain hijack, all services are canceled.
Edit
The most probable problem is: Your domain verification is failing.
Start the verification process again. This will give you a new TXT record to add to your DNS.
Go to your DNS providers page and add the record. While there look for the refresh value on the SOA record.
Convert the SOA refresh from seconds to hours. Divide by 3600.
Wait that amount of time + 4 hours for replication.
Use nslookup (or dig) and look for the TXT record. Be sure to use Google's DNS server at 8.8.8.8(server=8.8.8.8).
If the record is not found, wait some more, if (hours waiting > 72) break; else repeat check.
If nslookup was able to find the record, complete the verification process; if not contact your DNS provider(The client record hold can be an issue).
If at this point everything went well, You should have an authorized domain.
If not (domain disappears, contact Google support), It my have to do with the privacy settings on the domain. Most quote public domains have contact information.
You must use a TLD (top level domain). If you have a subdomain, it is owned by the person who owns the TLD. For example, you might have a blog at myamazingblog.wordpress.com, and wanted to use OAuth with it. Unfortunately, this would not be possible, since you do not own wordpress.com (the TLD).
Try testing on a different device or clearing cache.
For me it turned out I had everything correct (just with my example.com domain) but my iOS safari was caching something and it kept giving me the ‘not whitelisted’ message. Which led me to think I needed to add dev.example.com as well - which isn’t necessary.
So try going to the site on another device or browser to see if it works.
There's a subset of users which will not have access to the system I'm implementing in the beginning but I need a mechanism for them to capture data for one specific part of the process.
An authorized user creates the original record for a Person with some basic details i.e. First name, last name etc.
I then create a 'DataRequest' record which has a unique guid and the external user is sent an email with a path which is effectively http://sampleapplication/Person/Complete?guid=xxxx
The external user adds additional details like Date of Birth, Eye colour etc, submits and saves to the DB. The DataRequest for that guid is then expired and cannot be accessed again.
The Complete action doesn't have any authorization as these external users do not have user accounts.
My preference is to force these users to use the system but at this stage I'm not sure it's practical.
Is this a bad practice?
Should I be implementing some additional security on this like a one time password / passcode contained in the email? Are there alternative approaches I should consider?
There's nothing wrong with opening up a section of your site to the public. Tons of websites have secured and unsecured sections. However, there's also nothing saying that you have to expose your secure site at all. You can create another site that merely has access to that change those records and make that site alone, public.
As far as securing the information of the user, passcodes by email are the invention of some developer somewhere with limited mental ability or a severe lack of sleep. If the link is only available by email (not discoverable by search engines and not easily guessable), then anyone with the link will also have the passcode, making the passcode to access the link redundant.
You should however log when the email is used to finish the record and then disallow further uses.
I've gotten a good number of OAuth logins working on my site now. My implementation is based on the WebSecurity classes with amends to the code to suit my needs (I pulled the WebSecurity source into mine).
However I'm now facing a new set of problems. In my application I have opted to make the user email address the login identifier of choice. It's naturally unique and suits this use case.
However, the OAuth "standards" strikes again.
Some providers will return your email address as "username" (Google) some will return the display name (Facebook). As it stands I see two options given my particular scenario:
Option 1
Pull even more framework source code into my solution until I can chase down where the OpenIdRelyingParty class is actually interacted with (via the DotNetOpenAuth.AspNet facade) and make addition information requests from the OpenID Providers.
Option 2
When a user first logs in using an OpenID provider I can display a kind of "complete registration" form that requests missing info based on the provider selected.*
Option 2 is the most immediate and probably the quickest to implement but also includes some code smells through having to do something different based on the provider selected.
Option 1 will take longer but will ultimately make things more future proof. I will need to perform richer interactions down the line so this also has an edge in that regard.
The more I get into the code it does seem that the WebSecurity class itself is actually very limiting as it hides lots of useful DotNetOpenAuth functionality in the name of making integration easier.
Andrew (the author of DNOA) has said that the Attribute Exchange stuff happens in the OpenIdRelyingParty class but I cannot see from the DotNetOpenAuth.AspNet source code where this class is used so I'm unsure of what source would need to be pulled into my code in order to enable the functionality I need.
Has anyone completely something similar?
AttributeExchange only applies to the OpenID Providers (Google and Yahoo!) and you can see the extension used in their respective source files.
I recommend against using email address as the username. Email addresses can be recycled (an account can expire or be closed/canceled and the email address can be reassigned to a new user). If this happens, your site based on email addresses would "give away" all the data of the old user to the new user. Massive privacy violation and lawsuit potentially happening there. Far better to use the Claimed Identifier for the OpenID cases, or the service provider-specific user id number in the OAuth cases, as the primary identifier in your user table. Certainly you may capture and display the email address everywhere on the web site where you would display a username so as far as the user knows that's the username -- it's just that internally you use something more precise than that.
I have a cics application and i don't want to develop an login screen, instead i want to restrict the access by fetching the user id and then to verify if they are allowed to run my application. Is this possible? Thank you
There are probably better ways of restricting access to certain transactions within a CICS environment than by grabbing the USER ID and comparing to a list. Most shops have developed standard techniques for restricting access to transactions within CICS. However, if you must find the User Id, try something like this:
EXEC CICS ASSIGN
USERID(WS-USERID)
END-EXEC.
where WS-USERID is a working storage PIC X(8) field.
This is a link to the documentation for CICS ASSIGN.
EDIT
How to check against multiple user ids? You need a list of authorized users to compare the current user id against. If the
user id is in the list, the user is authorized to use the transaction. Typically you have a couple options for managing such a list:
SELECT against a database table containing authorized user ids. Use the current user id as the predicate (eg. WHERE USER_ID = :WS-USERID). If you get a row back, the user is authorized.
SEARCH/SEARCH ALL a WORKING-STORAGE table populated with authorized user ids for a match. If you get a match, the user is authorized.
The WORKING-STORAGE table solution is the least flexible since the program may need to be updated and re-compiled each time a new user is added or removed.
However, as pointed out by myself and cschneid, access security is best handled outside of applicaion programs
using something like RACF or ACF2. Your local systems
administration should be able to help you get this set up.
CICS can talk to an external security manager, such as RACF, CA-ACF2, or CA-Top Secret. Applications are often secured at a transaction level by having the correct rules or profiles in place in the external security manager.
This way, security actions are performed external to the application logic. Access is granted by security personnel and not by an application developer.
To follow on to your comment to NealB's answer regarding multiple users: Your security administrators can add all of the userids in question to a group, and then define access permissions to that group for your transaction.
You really should let your security administration handle transaction access. Good system design puts security management outside of the application.
With CICS TS V4.2 and above with the Security Extensions Feature Pack (integrated in V5.2) you can use SAML assertions coming from distributed applications to provide even more granular access control.
I'm hoping someone could enlighten me on the way authentication works with the new D2L REST API. From my reading and playing with the "GetStarted" example code it seems that calls are based on the "User Identity Level" and "User Acceptance".
For us, this is a bit problematic.
We haves several custom tools where a student completes an activity (outside D2L) and is given a grade. These tools are set up so that the grade provided in this manner are associated with a grade book column for a given course in our D2L instance. Currently with SOAP, we just use a privileged web services account so that when a student completed the task, the grade was automatically exported to the associated grade book column in the given course.
My understanding from the REST documentation is that it is no longer possible to use a privileged web services account, as it would have to sign in and accept the use of the tool each time. The student completing the task wouldn't have this information (nor would we want them too) and the student level of access wouldn't allow him to upgrade the grade book column so we wouldn't be able use his "User Identity" either.
The only alternative I can think of would be to store all the grades else where. Then, when appropriate, the instructor for the course would sign on and batch update the grade book using their "User Identity Level" and "User Acceptance"?
Is this correct?
For us, this is very cumbersome as we rely on own tool's authentication methods and the privileged web service accounts quite a bit.
An extra manual login is not required and there are two alternatives that I have seen used in this scenario. Both utilize the fact that the Valence authentication system uses keys and signatures. By using signatures rather than sending tokens even plaintext apis are not subject to session hijacking and as a result keys can safely remain valid for a long time. This period is typically set to 30 days, but, when applications like the one you describe are in use it is best to have no timeout. You can contact support about adjusting this timeout for your server. (Keys are still reset if passwords are reset or if they are explicitly revoked).
With long lived keys the following scenarios are possible, without the application directly receiving or storing the users password (key storage still needs to be done securely):
Instructor account context: If the application workflow already requires an instructor to activate or configure the process the userid and userkey for that instructor can be retained during the intial session and later used to submit the grades. This does not require any special accounts or elevated priveleges, but, only applies if the workflow already involves the instructor context.
Utility account context: If the application does not involve an instructor, it is possible to create a utility account that has permissions to update grades. This is often the approach already in use with D2LWS, but, with an extra step. In this scenario, the keys for the utility account are established out of band (for example the getting started sample (http://docs.valence.desire2learn.com/samples/gettingStarted.html) will display the keys). Alternately an install or config type process can be created that automatically records the keys from the utility account. After these keys are recorded no additional interactive sessions are required.