Is OnePass Needed for a UDS Session?

Disregarding everything that would need to change in Website, is a OnePass account actually needed in order to establish a UDS session? Another way to ask: Is it possible to create a Cobalt product that does not use OnePass without significant changes to modules besides Website?

Best Answer

  • OnePass is NOT required in order to establish a UDS session. In fact, it was only within the last year or so that OnePass absolutely became required for WestlawNext (prior to that certain trial or test passwords were allowed to bypass OnePass). OnePass **is** required in order to access Data Room, although work is underway in Data Room to support alternate OAUTH credentials (a SAML token from a trusted source). At least minor changes would be needed in UDS and Data Room to support a new credentials source, but a pattern for using OAUTH/SAML is being established for a new non-Legal product being developed on the Cobalt platform.

Answers

  • Awesome, could you elaborate a bit on what is needed? Is there still a regkey of some sort, or PRISM id, or really anything regarding who the user is that UDS needs? The reason why is I am on a project that might have A LOT of unique and unidentified users and I want to look at all options.
  • UDS does require some sort of user id (anything 40 bytes or less), and certain other fields, but it does not have to be a valid Prism user guid. Just for session creation, UDS assumes other modules are co-ordinating the authentication (perhaps through calling other UDS apis, that are independent of session creation.) More details on which session fields are required can be found on the UDS wiki:
    http://nsawiki.int.westgroup.com/wiki/index.php5/Session_Management#Session_Object
  • The Data Room OAUTH/SAML processing is still under development, but when completed, it will support creation of a DR WorkProductToken using a SAML assertion, from a recognized, trusted source, that contains all the information that DR needs to identify the user and the user's access information (eliminating the need for Prism Security and OnlineCharges.) Callers will still be able to create the OAUTH WorkProductToken via UDS, assuming UDS knows what api to call for that product, to obtain the SAML assertion.
  • Just to clarify terminology which you are mixing. SAML and OAuth have NOTHING to do with each other. Each use different techniques for secure authentication. SAML is for access INTO something else, and is should really only be used for browser based apps (which is what it is designed for). OAUTH is a completely different technique, that STILL requires some form of browser (for the use to authorized access). If DR is using either of these, it can be problematic. OAuth is the closes, but DR doesn't have it's own authentication.
  • I used that terminology because the Data Room api to create the WPT is currently called "CreateOauthToken" but it accepts an encrypted SAML assertion. It may change by the time development is completed.