I guess the question is what kind of topologies we want to support. For example, if we wanted to support a multi-tenant OC then it would be harder to do using SSL. On the other hand, I can see in the scenario you describe where this is a single cohesive infrastructure, then it would be simpler using SSL.
I have sat through about 10 reviews where we have said we should move to OAuth to handle the authorization/authentication between the admin console webapp and the backend servers. So why has that thought changed? Paul On 29 May 2013 09:29, Shameera Rathnayaka <[email protected]> wrote: > Hi Paul, > > On Wed, May 29, 2013 at 1:25 PM, Paul Fremantle <[email protected]> wrote: > >> So my personal experience is that setting up Mutual SSL and getting the >> keys working is not quick or simple. I know its a well-known thing and some >> companies will be doing this a lot, but its still an effort. Managing the >> SSL keys when they expire is also complex. >> >> I don't see why there can't be a simple one-time password entry by the >> administrator the first time they install OC, which will generate the OAuth >> key and then we cache it in the secure vault. >> > > As new managers get registered with OC dynamically(not pre configured) and > manager node of particular cluster starts the registration process, I am > wondering whether we can use above approach in such an environment? > > Thanks, > Shameera. > > >> >> Paul >> >> >> >> On 29 May 2013 07:17, Amila Suriarachchi <[email protected]> wrote: >> >>> >>> >>> >>> On Wed, May 29, 2013 at 11:19 AM, Paul Fremantle <[email protected]> wrote: >>> >>>> I understand the picture. What I don't understand is the statement "it >>>> will be more convenient". Can you please explain why Mutual SSL is more >>>> convenient than OAuth? It certainly is less convenient for the ops guys who >>>> has to set it up! >>>> >>> >>> If we use OAuth we need to have an access token. How to generate this >>> access token and where to store that? If we compare this with mutual SSL >>> there is a standard way to generate the certificates .Company may already >>> have a certificate and we can use jks to store them. >>> >>> The problem with the Mutual SSL is once we enable Mutual SSL for a port >>> we can not communicate with that port through a browser. So we may need to >>> use two ports one for browser and other for mutual SSL. >>> >>> thanks, >>> Amila. >>> >>> >>> >>> >>>> >>>> Paul >>>> >>>> >>>> On 28 May 2013 08:42, Ananda Manoj Kumara <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> On WSO2 Operation Center use case we need to securely communication >>>>> between OC and Manager nodes (server to server communication) about >>>>> cluster >>>>> information and other management information. According to the design >>>>> discussions it was suggested to use 'mutual authentication' during >>>>> communications. >>>>> >>>>> Currently Jaggery did not support server to server communication and >>>>> it use OAuth for communication using server credentials. But considering >>>>> OC >>>>> use-cases we need to maintain states of manager nodes periodically with OC >>>>> and we feel that it will be more convenient to use mutual authentication >>>>> through certs than accessing admin services using current OAuth >>>>> implementation. >>>>> >>>>> Your ideas are welcome about this matter. >>>>> >>>>> Thanks, >>>>> Manoj >>>>> >>>>> >>>>> Best Regards.. >>>>> >>>>> >>>>> Manoj Kumara >>>>> Software Engineer >>>>> WSO2, Inc.; http://wso2.com >>>>> >>>>> Twitter: http://twitter.com/ManKuma >>>>> Mobile: +94713448188 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Paul Fremantle >>>> CTO and Co-Founder, WSO2 >>>> OASIS WS-RX TC Co-chair, VP, Apache Synapse >>>> >>>> UK: +44 207 096 0336 >>>> US: +1 646 595 7614 >>>> >>>> blog: http://pzf.fremantle.org >>>> twitter.com/pzfreo >>>> [email protected] >>>> >>>> wso2.com Lean Enterprise Middleware >>>> >>>> Disclaimer: This communication may contain privileged or other >>>> confidential information and is intended exclusively for the addressee/s. >>>> If you are not the intended recipient/s, or believe that you may have >>>> received this communication in error, please reply to the sender indicating >>>> that fact and delete the copy you received and in addition, you should not >>>> print, copy, retransmit, disseminate, or otherwise use the information >>>> contained in this communication. Internet communications cannot be >>>> guaranteed to be timely, secure, error or virus-free. The sender does not >>>> accept liability for any errors or omissions. >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Amila Suriarachchi* >>> >>> Software Architect >>> WSO2 Inc. ; http://wso2.com >>> lean . enterprise . middleware >>> >>> phone : +94 71 3082805 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Paul Fremantle >> CTO and Co-Founder, WSO2 >> OASIS WS-RX TC Co-chair, VP, Apache Synapse >> >> UK: +44 207 096 0336 >> US: +1 646 595 7614 >> >> blog: http://pzf.fremantle.org >> twitter.com/pzfreo >> [email protected] >> >> wso2.com Lean Enterprise Middleware >> >> Disclaimer: This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may have >> received this communication in error, please reply to the sender indicating >> that fact and delete the copy you received and in addition, you should not >> print, copy, retransmit, disseminate, or otherwise use the information >> contained in this communication. Internet communications cannot be >> guaranteed to be timely, secure, error or virus-free. The sender does not >> accept liability for any errors or omissions. >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Software Engineer - WSO2 Inc.* > *email: shameera AT wso2.com <[email protected]> , shameera AT > apache.org<[email protected]> > * > *phone: +9471 922 1454* > * > * > *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561 > *Twitter : *https://twitter.com/Shameera_R > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, VP, Apache Synapse UK: +44 207 096 0336 US: +1 646 595 7614 blog: http://pzf.fremantle.org twitter.com/pzfreo [email protected] wso2.com Lean Enterprise Middleware Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
