Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>@Luis: Here are my inputs. </p> <p>Well exact solution for your problem depends upon kind of web service clients you expect, do you have control over web service client system, your app server etc.....but assuming you don't have any control over web service client, for you it is just a SOAP message over HTTP transport, here is probable solution.</p> <p>You can of course performs session management &amp; authentication at message level or transport level. It means either you can have session token and auth token information in SOAP message or you can use standard HTTP Session and HTTP authentication mechanism.</p> <p>Of course transport level solution is much simpler and industry wide standard in case if transport layer is HTTP. For message level, ws specifications like ws-security can be used. Your each web service request is simple HTTP GET/POST identified by a unique HTTP URI. Typically in jax-ws metro environment, WSServlet is one which entry servlet for any web service call and which eventually delegates the call to right service provider implementation class. Since you application is going to be deployed in web server, you can exploit all session and authentication facilities provided by J2ee web container.</p> <p>Since you are looking for role-based access control, I would use standard <code>&lt;web-resource-collection&gt;</code> in web.xml to specify which role you would like to have in case of particular HTTP URI. You can use standard JAAS login module which can do authentication and populates the JAAS subject with role. If user name/password are provided in SOAP XML, JAAS login module can also search/parse SOAP XML to retrieve those information. JAAS/app server will automatically create auth token and store it as cookie so that each subsequent request need not to go through authentication process again. This is all J2ee standard. You can find plenty of help on internet on this. Please let me know your app server so that I can provide you additional details.</p> <p>If you still want to use SOAP message level session management, authentication &amp; authorization process, then to provide you more details, may I know more details about your client side. </p> <p><strong>EDIT1:</strong> Well based on your further inputs, here is my more thoughts: Message security namely encryption and signature needs to happen each message travels between server and client. where as message authentication- you intend to do once and give a session token/auth token to client for subsequent calls.</p> <p>Question still remains: if you put a unique session Identifier in SOAP response of first time authentication, do you expect client to parse SOAP response XML and ensure that client should send you session identifier each time in subsequent SOAP requests. <strong>OR</strong> You want to keep session management transparent to client and for client it needs to send username/password token first time and subsequent calls need not require any username/password token. In this case you would need to rely on transport based session management for e.g. HTTP cookies</p> <p>Now what is the best for you depends upon your use case. Can you tell me what is expected use case flow? how another system (web service client) makes more than one service call to your system? Is another system user driven/some background process? What is exact need that you want only first service call to go through authentication process not subsequent calls? </p> <p>PS: Glassfish server provides a way of configuring message authentication provider which automatically enables/disables message level authentication.</p> <p><strong>EDIT2:</strong> I understand you do not want to store user credentials in client app and web service server need those user credentials. OAuth is open standard protocol which allows site A to access user's private data on site B. Ultimate idea is site A gets auth token which has specific expiry time. So Token containing encrypted from of user credentials or jsession id help you avoid need of re-authentication. <strong>You only need to decide where you want to keep token at client app side</strong> You can keep token as cookie if transport is HTTP protocol.</p> <p>Having said that ofcourse passing user credentials each time seems bit easier and straight forward.</p>
    singulars
    1. This table or related slice is empty.
    1. POJAX-WS, Authentication and Authorization - How to?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USag112
    1. USag112
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. COthanks for your help. I updated my question.
      singulars
      1. PO
      1. USlpinto.eu
    2. CO@Luis P: updated more information & queries:)
      singulars
      1. PO
      1. USag112
    3. COClients will use various services. My idea about a single time authentication, was to allow the client app to ask the user for the credentials, and don't need to store it. Something like OAuth (I thinks). But maybe could be easer to send the username/password in every call, and incorporate this in the message level security.
      singulars
      1. PO
      1. USlpinto.eu
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload