[아카마이] Akamai LUNA Webinar - Token Authorization (10월 19일,  오후 2시)

Document created by Jieun Jung Employee on Oct 18, 2016Last modified by JungUn Kim on Oct 31, 2016
Version 5Show Document
  • View in full screen mode

[아카마이] Akamai LUNA Webinar - Token Authorization (10월 19일, 오후 2시)

 

안녕하세요, 10월 19일에 있었던 Token Authorization 에 대한 웨비나가 성원리에 마무리 되었습니다.

관련 비디오 첨부하오니 참고 해주시기 바랍니다.

 

  • Akamai Edge Authorization 2.0  (20 mins)
    • Akamai Edge Authorization 2.0개념
    • Token 생성방법
    • Best Practice
  • Luna Control Center – Alert 설정 (10 mins)
  • Q & A  (20 mins)
    • 세션 주제 이외의 질문도 환영합니다!

 

 

웨비나중에 나왔던 Q&A에 대하여 올려 드립니다.

문서작업 및 내용 업로드는 김정언 부장님께서 도움주셨습니다.

 

김정언, 부장님 감사합니다.

 

Q1. Action을 Verify로 설정하면 확인은 어디에서 어떻게 할수 있나요? 로그인가요? 헤더가 따로 있나요?

pragma 헤더로 확인하실 수 있습니다.
Pragma: akamai-x-get-extracted-values 을 추가하신 후에 X-Akamai-Session-Info: name=PM_TOKENXX_STATUS; 의 value 를 확인하시면 됩니다.
 
ex) X-Akamai-Session-Info: name=PM_TOKEN2_STATUS; value=success

Q2. Key값은 임의의 문자열 아무것이나 사용할 수 있나요?

Hexadecimal format 의 문자열을 사용하셔야 합니다. Property Manager에서 random한 key값을 생성하실 수도 있습니다
ex) aabbccddeeff00112233445566778899

Q3. -acl의 delimiter 는 "!"로 해야하나요? 아니면 다른 문자열도 활용 가능할까요?

Configuration과 Token Generator에서 다른 Delimiter로 변경하실 수 있습니다. 다만 Configuration은 Metadata에서 직접 수정해야하는 작업이 필요하여 아카마이 서비스로 문의하셔야 합니다.
1) Configuration 에서 Delimiter 수정
    <auth:browser.token.acl-delimiter>!</auth:browser.token.acl-del imiter>


2) Token Generator에서 Delimiter 수정
    --acl_delimiter=ACL_DELIMITER 를 사용하여 delimiter를 변경하실 수 있습니다.

Q4. --window 최대값은 어떻게 되나요?

일반적으로는 최대값 제약이 없다고 할 수 있습니다. 다만 토큰을 생성하시는 해당 언어의 library에 따라서 최대값이 있습니다.
예를 들어 Java library를 사용해서 토큰을 생성하시면 long type 변수를 사용하니까 실제로 생성하실 수 있는 값은 long type range까지 가능합니다.

Q5. 접속시간은 30초이고 용량이 커서 다운로드 시간이 60초이상 이라면 30초 이내에 다운로드 시작한 접속은 다운로드가 완료될때까지 유효 한가요? 아니면 다운로드 중간에 끊어지게 되나요?

Token 인증 로직은 최초에 Cache 서버에 접속하는 시점에서만 동작하며 끝난이후 부터는 다시 실행되지 않기 때문에 Request를 끊고 다시 실행하는 Case를 제외하고는 Expire time을 초과 하더라도 Download에 영향을 주지는 않습니다.

Q6. 오늘 설명해주신 예제에 따르면 Token의 재사용을 방지하는 기준이 전적으로 IP 옵션에 기반하는 것으로 판단됩니다. IP 옵션을 사용하는 것이 불가능한 경우에는 Token의 재사용을 방지하기 위하여 어떤 옵션을 활용할 수 있을까요? 추가로 토큰 생성 시 --session_id 옵션을 사용할 수 있는 것으로 알고 있는데 해당 옵션의 사용방법과 적용한 reference가 있는지요?

현재로써는 IP Address 옵션을 제외하고는 재사용 방지를 위해서는 만료시간을 짧게 운영하시는 것을 권장합니다. 말씀하신 session_id option은 현재 사용되지 않고 있는 option 입니다.
다만 아카마이 서비스팀에게 구현하시고 계신 서비스의 구조를 안내해주신다면 Token Auth에 추가적인 Authorization을 구현하여 최대한 방지할 수 있도록 개선할 수 있을 것 같습니다.

Q7. salt 값이 EOL 옵션이라고 하셨는데, 현재 사용중인 경우 언제까지 쓸 수 있는 것인지 궁금합니다.

장기적으로 EOL(End Of Life)의 계획을 갖고 있지만, 아직 구체적인 일정이 나와있지는 않습니다. 다만 향후 EOL이 계획된만큼 salt의 사용보다는 Encryption key의 사용을 권장하고 있습니다.

EOL일정이 구체적으로 나온다면 사전에 공지해드리도록 하겠습니다.

Q8. 같은 Path에 QueryString, 쿠키, 헤더 함께 사용할수 있을까요?

기본적인 Auth Token 2.0 Verification의 behavior로는 설정이 어렵지만 아카마이 서비스팀에 요청하셔서 고급 설정을 추가한다면 가능합니다.

구현시에는 Query String, Cookie 그리고 Header로 적용되는 각각의 인증에 대해서 모두 인증 성공시 성공으로 처리할지 아니면 조건중 1개만 성공하더라도 인증 성공을 처리할 지 정책이 필요로 합니다.

Q9. 시간 unixtime이라고 하셨는데, 실제 URL 발급하는 서버의 시간이 중요할 듯한데 윤초 이벤트 등등 시간관련 혹시 주의할점이있을까요? 시간 싱크가 안맞으면 인증 실패할 것 같은데 맞나요?

인증에 있어서 Millisecond 단위의 동기화 까지는 아니더라도 Token generator 서버와 Cache 서버간의 시간 동기화는 중요한 부분이 맞습니다.  

그 리고 실제로 2015년 7월 1일 윤초가 적용된 시점에 만료시간을 작게 설정한 한 고객사에서 부분적인 장애가 발생한 적이 있습니다. 그 당시 문제는 고객사의 Token 생성 서버의 time이 윤초 적용에 Delay가 발생한 Case 였습니다.

따라서 윤초와 같은 Time에 대한 event가 있으면 Start time과 End time 혹은 Window 값을 평상시 보다 여유있게 운영하시는 것을 권장해 드립니다.

참고로 2016년 12월 31일 오후 11시 59분 59초에 윤초가 삽입되는 것으로 예정 되어있습니다.

Q10. Q5번 질문에 따른 후속 질문입니다. Token의 window 기간 경과 시 다운로드가 끊어지는 것을 실제 적용 후 확인 했습니다. 이와 같은 증상이 POC(Partial Object Caching)를 설정한 경우에만 발생하는 것인가요? 아니면 일반적으로 발생할 수 있을까요?

Q5 에서 답변을 드린 것과 같이 인증은 최초에 접속한 시점에서만 동작하므로 일반적인 Case에서는 문제가 되지 않습니다. 

또한 POC(Large File Optimization)를 사용하는 Case라고 하더라도 Client <=> Cache서버 사이에만 인증을 설정한 Case라고 하면, Edge authorization 2.0은 인증 성공이후 Download에 영향을 주지 않은 것이 일반적입니다.

다만 Edge authorization 2.0 와 POC(Large File Optimization)를 같이 사용할 경우 아카마이 서비스팀의 설정 지원을 받으셔야합니다. (Advanced 설정을 요함.)

Q11. 설명에는 특정경로에 token auth시 Criteria에 경로를 입력했는데, 꼭 경로 입력을 해야하나요?

꼭 path를 사용하실 필요는 없으십니다. 인증이 적용되어야하는 실제 조건을 설정하시면 됩니다. 전체 적용이 필요하다면 Criteria를 비워두셔도 됩니다.
사용가능하신 Criteria(조건)는 client-request stage에서 동작하는 Criteria를 대부분 사용하실 수 있습니다.
만약 client-reponse stage에 인증 적용이 필요하다면, 고급 설정이 추가 되어야 하므로 아카마이 서비스 팀에 문의 부탁드리겠습니다.

Q12. td <->origin 구간에서 인증 파라미터로 구분되면 전달이 되지 않는 것으로 알고 있는데, 옵션으로 조정할 수 있으면 좋을 것 같아 남겨봅니다.

좋은 의견 감사합니다.

관련된 의견을 본사측으로 전달하도록 하며, 추가적인 업데이트가 있다면 Community를 통해서 공유하도록 하겠습니다.

2 people found this helpful

Attachments

    Outcomes