キークロックで、ロジックオーサイレゼーションを 作ることを説明します。アーキテクトを作ることを 確保しています。このセッションは、 オーサイレゼーションを作ることを 作りましょう。まず、私の自分のアイテムを 説明します。私の名前は 吉比田畑です。私は、 オーサイレゼーションの コンサルタンです。私は、 セ英シからする多めの 働いた。私は、アーキテクト私のコンサルタンで のでこれは私、これは私がアーカイ系の ボスバース ouするオーサイレゼーションでの特徴 beautiful focusedオーセンティケーションオーサイレーションand the API management.For example, I contribute to Key Clock,IHT and Access Management OSSand Sleet Scale and API Management OSS.For these OSSI mainly develop features based on feedbackfrom actual projects like the above fields.And other activities I spoke at eventsエピアデース、エピアスペースケーション コンフォレンス、オースセキュリティーワークショップ、そしてその他のものです。そして、私は彼らのアイデンティー アクセスマジュメントについて説明しました。それでは始めましょう。まず、今日のコンテンツです。まず、オーサリゼーションの重要性を 描くことを説明します。そして、オーサリゼーションの スケーブルオーサリゼーションを描くことを説明します。今までは、オーサリゼーションとの大事なオーサリゼーションを 埋めるのは、之後にコンテンツ付いてオーファー 埋めることを説明しました。まず、オーサリゼーションの重要性を描くことを説明します。まず オーサリゼーションは何を言うのか?オーサリゼーションは 世代のコンビネーションを作る事に remains unproven activitiesオンセナリティサリとは不同ですオンセナリティサリは安定さ俺の個人情報性決刻のやりたいオンセナリティサリという資訊性は不要です例えば、ない種類のサーナーにはオンセナリティサリで適当な技能があるが、オーセンティケーションはリクエスに適切な技能をつけたりはある。例えば、オーセンティケーションを使っている社会の価値を抗うことができる。このようにオーセンティケーションとオーセンタの系統を分解するための重要な技能が要素。今日はオーセンティケーションに移行してみます。オーサイズレシピは 重要なセキュリティーを考えます例えば オーサイズレシピの10のエピアセキュリティーのリスク3のトップ5のセキュリティーリスクは オーサイズレシピの世界に入っています1. オブジェクトレベルオーサイズレシピ3. オブジェクトプロプティーレベルオーサイズレシピそして5. ファンクションレベルオーサイズレシピI briefly explain each security risksregarding number 1 ブロークオブジェクトレベルオーサイズレシピthis risk allows access to objects not permittedfor example user 101 can get user 102's resourcesthe resource server must not allow user 101 to obtain user 102's resourcesregarding number 3 ブロークオブジェクトプロプティーレベルオーサイズレシピthis risk allows access to objects properties not permittedfor example a general user 101 can change its rank to gold rankthe resource server must not allow a general user to change sensitive object property like rankregarding number 5 ブロークオブジェクトプロプティーレベルオーサイズレシピthis risk allows access to prohibited functionsfor example a general user 101 can call administrator functionsthe resource server must not allow a general user to call administrator functionslike this there are various level of authorizationall of which are considered high security risksso you can see how important authorization isnext I describe what scalable authorization isthe simplest authorization implementation is implementing it in application logicfor example when you'd like a user to access the protected resourceif they are an administrator you can implement it like thisif user.isAdmin then user can access the protected resourcesthis is a common implementation that we often seeand there is nothing wrong with implementing authorization this wayhowever as the service growsthe authorization logic quickly gets difficultfor example you may need to allow to access the protected resourcenot only for administratorsbut also for full-time workersor the resource management group membersin this case the number of conditions in the if statement increases dramaticallyalso in many cases duplicate implementations may be requiredin multiple places in the application logicor for multiple servicesthis is not a scalable authorization implementationtherefore some kind of ingenuity is requiredto make authorization implementation scalablethere is a common approach to ensure scalabilityby managing roles in a hierarchical structurethere are two layersthe user layers and the resource layerthe user layers roles are assigned to usersand the resource layers roles are assigned to resourcesfor example user101 is a directorand a full-time workerand belongs to the administration departmentin this case user101 will have the administrator roleof the resource servicein this case you only need to implement authorization like thisif user dot has a role resource service dot adminthen user can access the protected resourceeven if the authorization condition changes laterthe change will be absorbed by the role hierarchyas a result this reduces the impact on application logicin other words even if you may need to change the conditionsof who can access a protected resourceyou only need to change the relationshipbetween the user layers rolesand the resource layers rolenot to change the conditions of this if statementthis means authorization logicwere able to be separated from application logicit seems like high scalabilityhowever as the service growsthe number of roles increasesand there is a risk of a role explosionwhen role explosions occursystem performance is severely degradedothermore from another point of viewto authorize users by these rolesmultiple services may need to store duplicate role datain the end this is still low scalabilityand not a scalable authorization implementationso far to summarize what the idea-scalable authorization isto use the same application logicfor multiple servicesand to eliminate duplicate data as much as possiblein this example all servicesuses the same authorization logicwhich uses URIsspecifying resources and HTTP methodsspecifying what you do for the resourcesif what you need to implement for authorizationis only thisthis must be a scalable authorizationto realize this you need two thingsto separate authorization from application logicand to centralize authorization datanext I introduce how to implementthe idea-scalable authorization with kickrockfirst how to separate authorization from application logicto separate authorization from application logicthere are two waysimplementing authorization logic from scratchor using an external authorization servicethere are pros and consregarding from scratch wayif simple purpose from scratch is betterit is difficult to achieve fine-grained authorizationregarding the external service waymany services allow to definition of general purpose policiesto achieve fine-grained authorizationhowever the more general purpose policy definitionsare made possiblethe higher the learning costsfor defining policy tend to behere I will introducekickrock's authorization serviceas a just right purpose authorization servicethe meaning of just right purpose isthat kickrock's authorization serviceis based on avocattribute-based access control architectureand acts as PDPpolicy definition pointthis can achieve fine-grained authorizationlike the external service waybut by using kickrockwe can configure authorization using GUInot needing learning costshere I briefly introduce kickrockkickrock is identity and access management OSSand kickrock provides OS 2.0authorization server featuresand single-signal featureskickrock became a sedentive incubating project this Aprilhere I introduce four mainmeasure featuresfirst kickrock supports standardssuch as OS 2.0openly connect and sum upand so onand second kickrock can connect toexisting user stores held up and active directory serversthird kickrock can log inwith social networksgithub twitter facebook etcfinally kickrock provides a policy-basedauthorization serviceI describe kickrock's authorization servicein a little bit of detailby using kickrock's authorization servicewe can centralize authorization datato kickrock and eliminate to storageof duplicate authorization data in multiple serviceskickrock enables fine-grade authorizationby resource, scope, policyand permission managementthis management can be done by using kickrock GUIresource is a protected resourcethat needs to be authorizedscope is an actionthat can be performed on resourcespolicy is a conditionthat can be satisfied to access or perform operationspermission is coupling the policywith the protected resources and scopeskickrock can act as a PDPand make an authorization decisionusing these four types of definitionsthis example showshow to achieve scalable authorizationwith kickrock's authorization serviceby using authorization to kickrockand getting an authorization decisionpreviously required multiple API requestsbut now you can get an authorization decisionwith just one API requestthis is enhanced in kickrock 22and I committed to thiswhen delegating authorizationyou request the kickrock's token and pointwith an access tokenthat represents the userand specifyUMA ticket to grant typedecision to response modeURI and scope to permissionthen kickrock returns an authorization decisionjust results to or forin this example using thehtt method as scopeand the URI as resourcethis means authorization logic wasable to be separated from application logicand when the number of services increaseswe only need to write this same logicthen achieve the same kind of authorizationso it must be a scalable authorizationnext I focus on this access tokenthis is the overall flowof authorization and authentication by using kickrockaccording to OAuth 2.0the standard protocol for API authorizationwhen a client requests APIthe client commonly adds an access tokento the API request for authenticationso a service delegates authorizationwith the access token and kickrockevaluates policies using the access tokenplace an important rolefortunately kickrock can also actas an OAuth 2.0 authorization serverkickrock can issue the access tokenfollowing the OAuth 2.0 authorizationcalled grantI briefly describe this overall flowwhen a user uses a clientthe client makes an authorization requestafterward kickrock authenticatesand authorize the userthen makes an authorization responseafterward clients request tokenand kickrock issue tokensthen the client request an APIof the service with the access tokenthe service delegates authorizationwith the access tokenand authorization decision from kickrockif the authorization succeedsthe service returns a responseI mapped the standard specificationsto this overall flowthis token issurance is followingthe RFC 6749 OAuth 2.0authorization called grantand API request is followingthe RFC 6750 OAuth 2.0and authorization delegationis following ABACby using kickrock in this wayyou can achieve both API authorization and authenticationin a standards compliant and secure wayfor your reference I introduce another standard specificationcalled UMAuser managed access 2.0 grantby following the UMA 2.0 grantcan define permissions for their resourcesto third partiesso more flexible authorization is possiblewith various use casesfor example, a use case in which a resource ownerwants to publish their resources tosome third parties, third party clientsanother example is a use case in which resource ownerwants to change authorization policydynamically depends on their circumstanceskickrock is a UMA 2.0 compliant authorization serverthat provides most UMA capabilitiesfinally, I introduce advanced challengeswith opera and cockroach TVas I said before, to realize scalable authorizationyou need to centralize authorization datahowever, there is room for considerationof which is better centralized authorizationor distributed authorizationdistributed authorization meansauthorization at the edge of each servicehere I focus on the disadvantagesof centralized authorizationand tackle reducing the disadvantageshere for perspectives are listedscarability, performance, availabilityand consistencyregarding scalabilitycentralized authorization is better as I introducedin previous slidesthis is because multiple services do notneeds to store duplicate authorization dataand authorization logicregarding performance, distributedauthorization is betterbecause services only need to accesslocal authorization logicon the other hand, in centralized authorizationwhen centralized authorization servicesaredue to access the centralized authorization servicefor every API requestso this communication might have a negative impact on performanceregarding availabilitydistributed authorization is betterbecause even if some services go downthe rest services go well using their local authorization logicand centralized authorization services go downall services deny every API requestregarding consistencycentralized authorization is betterthis is because only the authorization servicemakes authorization decisionsso consistency in authorization decisionsbetween services is guaranteedthis is a common comparison betweencentralized authorization and distributed authorizationhowever, when performing decentralized authorizationwith KeyClock, this comparison is somewhat differentthis is because KeyClock is a member of CNSF familyand can be deployed in the samecompanies cluster as a servicethe performance delays due to communication are reducedalso regarding availabilityby scaling KeyClock instancesand making it a high availability configurationwe can reduce the risk of SPOFsingle point of failurealthough only with KeyClockwe have already reduced these disadvantagesin the next slides, I introduce other solutionsfirst, tack the performance challengeas I said, KeyClock is in the CNSF familyin local Kubernetescommunication to the centralized authorization serviceless has negative impacthowever, when performance requirements are too severenot to ignore the communication cost to KeyClockthere is another solution combined with OPPAas you may know, OPPA open policy agentis a general purpose policy engineusing the policy language called regalthere are mainly two options combined with OPPAoption one uses OPPA as just a cachethe sidecar OPPAjust by caching authorization decision from KeyClockand we can expect performance improvementof course, there is a trade-off with consistency in authorization decisionin this option, a service delegatesand OPPA cachesuntil the cache expiresthe service only needs to access local OPPAoption two uses OPPA as PDPpolicy definition point as shown below figurewe move the PDP functions to OPPAand dedicate KeyClock to PAPpolicy administration point KeyClock just by notifying events such as policy changesof course, OPPA requires storing duplicate authorization informationin this option, a service delegates authorizationto OPPAand then OPPA makes an authorization decisionby checking to stored authorization databy combining KeyClock with OPPA in these wayswe can solve the performance changenext, tack the availability changecombined with OPPA as mentioned before KeyClock resolve the availability change to some extentthis is because even if some services go downthe rest services go well using their local OPPAhere I would like to consider not only local failuresbut also wide area failuresCritical services that cannot stopcombined with Cockroach DBKeyClock can withstand regional failuresand operate in multi-cloud environmentsas you know, Cockroach DB is a new SQL DBand has multi-region capabilitiesas a note, KeyClock plans to support Cockroach DBbut doesn't officially support it yetby combining with Cockroach DBeven in the event of regional failuresor large-scale cloud failuresservices can go well by changing the connection destinationin the case of Cockroach DBby adoption and active strategythere is no need for kind of failover processingin the event of a failureso down time can be minimizedin this way by combining KeyClock with Cockroach DBwe can solve the availability changefinally, this is a summary of this sessionfirst, authorization is becoming more and more importantsecurity considerationthis is clear from worst top 10 APA security risksthat three of the top five security risks include authorizationsecond, to achieve scalable authorizationseparating authorization from application logicand centralized authorization data are the keywordsand I introduced how to achieve scalable authorization with KeyClockfinally, regarding the comparison between centralized authorizationand distributed authorizationI described these advantages of centralized authorizationcompared to distributed authorizationthen I described that KeyClock can reduce these disadvantages furthermore, I described that combined with Operawe can solve the performance challengeand combined with Cockroach DBwe can solve the availability challengethese are trademarksand that's all, thank you for listeningdoes anyone have any question?is there a mic?can you hear me?do you have a proof of concept or some kind of demoof the scalable authsy system that you presented?which thread do you mention?is it with Cockroach DB or Opera?further back, this slideis there some kind of demo example that you could provide us?your question is there any demo for authorization service?not right now, just perhaps we could talk afterwardsif you have some kind of example to showin this session I didn't prepare the demobut we can show some demomaybe Hitachi booth or KeyClock booth in this eventso if you visit the boothwe may be able to show demothank youI have a question too about high availability with KeyClockbut right now KeyClock supports HAwith distributed caching using Infinispanso I'm wondering why would you recommendwaiting to use Cockroach DB instead ofusing distributed caching at the momentsince it's already supportedokaythank you for questioning the KeyClockas you mentioned that uses Infinispanclass configurationbutcache layers configurationyou may need to considermorelevel layers configurationthen we need to configurewe need to consider this kind of approachand this is not only focused on thelocal failures but also wide area failuresso maybe the one option for disaster recovery scenarioso I introduce this kind of configurationthank you