Jenkins 권한 설정 Jenkins 관련 두번째 포스팅이다. 이번에는 권한에 관련된 내용들을 기록하려고 합니다. [앞서 포스팅] Jenkins OIDC로 인증 연결하기 에서 Authentication의 한 종류인 OIDC를 이용한 셋팅을 해보았고, 이번에는 Authentication 이후 Authorization에 대한 설정들을 정리해보려고 합니다. 매우 유사한 단어처럼보이지만 한국어로도 확실히 분리된 개념입니다. 인증, 입증 / 인가, 허가... [인증]은 상대방이 시스템 진입에 허락된 사람입을 입증하는 과정이고, [인가]는 특정 사람에게 어떠한 권한이 허가 되어있느냐에 대한 설정입니다. 예를 들면 권한 설정에서 A라는 사람에게 1,2,3 이라는 기능 사용이 허락되어있다고 한다면 A라는 사람임을 확..

Jenkins 엄청 유명한.. CICD로 많이 사용되는 툴이다, 하지만 CICD라는 용어와 개념을 접해보지 못한 사람에게는 생소할 것 입니다. CICD는 Continuous Integration / Continuous Delivery의 약어로, 새롭게 업데이트되는 코드들이 지속적으로 산출물로 자동 완성되는 개념(CI)와 User에게 끊임없이 전달되는 새로운, 개선된 서비스들을 칭하는 의미(CD)로 Devops라는 문화와 맞물려 빌드 파이브라인이라는 용어로도 많이 사용됩니다. Github에서 제공하는 Circle CI, Travis CI 등 많은 관련 기능을 위한 다른 훌륭한 툴들 또한 존재합니다. 저는 개인적으로 CICD외에도 많은 자동화에 Jenkins를 즐겨 사용하는 편 입니다. 궁극적으로 Jenki..

앞서 Part에서 Frontend 측에서 Browser를 통해 IDP를 거쳐 code를 받는 것 까지 진행되었습니다. Confidential Type의 인증은 최종적으로 Secret을 이용하여 access token을 받게 되는 데 이 Secret은 Backend 에서 보관하고 있는 것이 안전할 것입니다. Static에 해당하는 부분은 Browser에 보여질 때 실제로 Client측에 그대로 Download 되어지기 때문에 Client측에서 Secret을 사용하려고 하면 그대로 노출이 되게 될 것 입니다. 앞서 User가 ID, PASSWORD를 입력해서 받은 CODE를 가지고 backend로 가져와서 실제 Token을 발급받고, 이 Token을 이용해서 IDP로 부터 USER의 정보도 받아보도록 하려고..

사용할 IDP를 설정했으므로, 이제 본격적으로 User에게 Input을 받을 Frontend 그리고 최종적으로 인증을 완료하고 Token을 받게될 Backend를 구현해보려고 합니다. Frontend쪽은 React 기반의 Javascript, Backend쪽은 Gin 기반의 GO 언어를 이용해보려고 합니다. 실제 Flow을 이해하고 나면 어떤 Framework, Language를 사용할지에 대한 건 큰 문제는 아닙니다. 구현하는 과정에서도 단순히 Curl 명령으로도 이를 수행할 수 있음을 짚고 넘어갈 것 입니다. IDP로 인증 요청하기 이제부터 단계별로 진행 해나갈 FLOW 입니다. 먼저 [Request static page]는 Browser로 Service하는 웹사이트에 접속하는 단계이므로 지금부터 진..

OIDC... Open ID Connect 일명 OIDC ... 요즘 많은 사이트에서 볼 수 있는, 카카오, 네이버 로그인, 페이스북, 구글 계정 등으로 로그인과 같이 서비스를 제공해주는 측에서는 민감한 사용자의 개인정보 (아이디, 패스워드등)을 회원가입을 통해 수집/보관하지 않고 사용자를 인증하는 과정을 Provider측에 위임하는 형태의 서비스를 많이 볼 수 있습니다. 이는 사용자 입장에서도 불필요하게 작은 사이트에도 회원가입을 일일이 해야하는 수고로움을 덜어주는 좋은 방향인 듯 합니다. Provider 측에서는 사용자가 접속하는 서버의 정보들을 다 수집할 수 있긴하겠지만... 사실 OIDC 이전에 SAML 2.0, OAuth 2.0 등의 IDP(IDentity Provider)도 있지만, 가장 최근..