블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'API Security'에 해당되는 글 2

  1. 2013.07.06 Open API design
  2. 2013.06.08 Federation과 SSO 에 대한 주요 표준 (메모)
 

Open API design

아키텍쳐 /SOA | 2013.07.06 13:14 | Posted by 조대협

OPEN API Design Consideration Point


1. API Type 

Internal APIs

Internal System in same network

User for internal user or authorized user

 

External APIs

for Public Developer

Developer Support is key point

 

for Partner

- Business value is key

 

2. API Design Best Practice

Easy to use

with out documentation, API should be easy enough to use.

Easy to Try and use

For private APIs, it is important to demonstrate real value in running a system or app off of the API

public APIs, one approach is to offer some level of free access. Many developers won’t even consider using your API if there are only paid options. At this point in the customer acquisition cycle, the developer may not know if your API meets their needs or if their app’s business model will support paid access.

 

Diffentiate API

Ÿ   The data is unique, more complete, or more accurate than that of your competitors

Ÿ   You offer better support or an easier signup process

Ÿ   Your API is more robust, reliable, cooler, or faster than alternatives

Ÿ   Your terms are more developer friendly; perhaps you offer more data traffic for free or at better rates

Provide mandatory functionality first time and enhance later

There are other aspects of simplicity that can help make your API easier to adopt. One success factor is to stick to conventions that the developer might already know

Target Specific Developer Segment 

3. Technology Selection

REST API

pragmatic REST API design

Figure 1 Wrong design for shopping cart

 

Figure 2 Good design for shopping cart

Binary protocol

Ÿ   Protocol Buffer

Ÿ   Thrift

 

Versioning

Having mediation layer like ESB

4. Security

Identification

- grant access by using API Key

Authenticate

- Determine who is accessing API.

Ÿ   User name & password

Ÿ   Session based

After log in with user name & password, session token key will be issued. with the session key authentication can be passed

Ÿ   Standard way

SAML

OAuth

 

Authentication vs Identification

Identification based API provides same functionalities and data to client.

Authentication based API provides user dependent data to client

Encryption

use SSL (can be attacked by Man in middle attack)

partial or all message encryption

 

Threat Detection and prevention

 

General recommendation of Security

API Keys for only nonsensitive & read-only data.

Use OAuth 2.0 for more sensitive authentication

use SSL for everthin sensitive data.

Sanitize incoming and outgoing data - prevent javascript attack and SQL attack. (especially in writable API)

 

5. Legal Consideration

 

Consideration point

- What content will be provided

- What right can u or do u want to grant the consumer of API

- Are they have different level of API access?

 

Perspective

Ÿ   Contract & Terms of Use

Ÿ   Privacy Policy

Ÿ   Data retention policy

 

6. API Operation

Monitoring

Throttling (Traffic management)

Depends on contract & consumer, API traffic can be managed. It is important to monetization

Reporting

SLA

Issue management

Internal operation issue tracking

Support

Ÿ   Issue management & ticketing

Ÿ   Documentation

Ÿ   Sand box

 

7. API Measurement

Effectiveness measurement - call per day

Effective measurement - call per day, call per client (by region ,model etc)

Performance measurement - response time

 

 

 참고

http://www.layer7tech.com/

http://www.apigee.com

 

 

'아키텍쳐  > SOA' 카테고리의 다른 글

Microservice architecture note  (0) 2014.08.20
Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29


Federation 기술로는 크게 


1. WS-Security가 있으며,

 상세 스펙으로는 

WS-Trust 는 STS 기반의 초기 인증과 토큰 발행

WS-Federation은 다른 리소스의 액세스에 대한 토큰 사용을 정의

을 정의


2. 반대 진영으로는 SAML 기반의 SSO가 있음


3. 그리고 B2C 진영에는 OAuth도 사용됨


주로 현재 대세는

SSO는 SAML을 사용하고,

API를 통한 특정 resource에 대한 접근은 OAuth를 사용한다.


구글을 사례

SSO 구현 : http://support.google.com/a/bin/answer.py?hl=ko&answer=60224

API 접근 : https://support.google.com/a/bin/answer.py?hl=ko&answer=61017&topic=2759255&rd=1