What's the sequence of endpoints in UDS authentication?

Joe Sauve

I'm on the WLN web team and working on an issue related to 400s coming back from a UDS call: /UDS/v1/systeminfo/availability. I'd like to know more about the sequence of UDS endpoint calls that occur (or should occur) during the course of a signon. I realize that I can look at the REST calls as they occur in Fiddler, but I'm just looing for some more expert knowledge on this.

Just to provide a little background, the 400 is coming back when the request header is too large. In this particular case, it's the BrowserHawk cookie that is oversized ( > 4K ) and is making the endpoint call puke. It seems like the BrowserHawk data needs to be persisted sooner, BEFORE the call to availability...BUT BrowserHawk's browser-detection supposedly occurs AFTER login. A catch-22!

So, that's a little perspective on the issue, but what I'm realy looking for is more UDS knowledge.

Thanks in advance!

Diane Swearingen

UDS doesn't do anything with cookies, so I think the 400 you are seeing is something returned either by BigIP, Apache or something in the java Infrastructure filters.
UDS also doesn't have a list of what MUST be called at signon, but here's a list of APIs that should probably be called, and the information they require/return dictates what order they should happen in:
1. [SystemInfo.Availability](http://nsawiki.int.westgroup.com/wiki/index.php/System_Information_Service#Checking_Service_Availability) -- This is needed for session throttling, so we don't let more users (of ANY kind) onto the applicaiton. AMS is in charge of setting the session limit numbers, using UberGui.
2. [Authentication.GetAuthToken](http://nsawiki.int.westgroup.com/wiki/index.php/Authentication_Service#Authentication.GetAuthToken) -- this should be called to get the Prism guid and Prism auth token, which is are some of the fields that Website must value when creating the session.
3. [Users.AccountInfo.Get](http://nsawiki.int.westgroup.com/wiki/index.php/User_Info_Service#Get_User_Account_Info) -- this endpoint calls OLC in the back end to retrieve certain details about the user (classification, name, etc.). In theory, if the call to OLC fails, it should not prevent the user from signing on, but it may mean certain features may not be available to the user during their session.
4. [AuthSession.Create](http://nsawiki.int.westgroup.com/wiki/index.php/Session_Management#AuthSession.Create) -- This accepts a Session object, which must have certain fields valued, and actually creates the session. This endpoint also does some system availability checking, not only for the overall capacity of the system, but whether the system is allowing signon of certain types of users (lawschool, etc.), since the session object should now tell us the type of user.
5. [Authorization.FeatureResourcePermissions.Get](http://nsawiki.int.westgroup.com/wiki/index.php/Authorization_Service#Get_All_Feature_Resource_Permissions) -- This endpoint can be called after a session is created, to get the list of dynamic feature resource permissions for the user.
6. [Preferences.Secure.GetAll](http://nsawiki.int.westgroup.com/wiki/index.php/Preferences_Service_(Secure)#Preferences.Secure.GetAll) -- This endpoint can be called after the session has been created to get all the user's preferences.
7. [AuthSession.Update](http://nsawiki.int.westgroup.com/wiki/index.php/Session_Management#AuthSession.Update) -- After more information has been obtained about a session, certain fields can be updated using this endpoint, including the status.