Claim based Authentication (CBA)

CBA Claim based authentication

ADFS 2.0 등 MS 진영에서 주로 사용함

- Claim : Subject를 identitify 할 수 있는 name, group 등 (쉽게 말해서 attribute)

- Token : Claim을 transpport하기 위한 packet ( 1개 이사으이 claim이 packaging되며, digitial signature로 packaging됨) ex) SAML packaging도 하나의 Token의 예

- Issuer: Token을 만드는 대상 (Idp가 주로 Issuer가 되는 경우가 많음)

- Secure Token Server (STS) : The central issuing authority. (In most case STS works as Idp) - 인증하고 Token 만들어주는 서버. (ADFS 2.0 )

- Replying party - Claim based authentication 을 사용하는 Sp (Service Provider)

Process

전체적인 흐름 자체는 SAML과 유사함.

사용자가 resource를 요청하면 STS (Idp)서버로 redirect해서 login 한후,  token 발급 받아서, 그 token으로, resource에 가서 인증하고 log in 하는 시나리오

1. User attempts to access an application.

2. User is redirected to the STS.

3. User authenticates to the STS.

4. The STS pulls claim information from the appropriate store and uses the information to create a token.

5. The token is sent back to the user.

6. Token is submitted to application.

3.7.2.1.1. Passive Client Flow

1. User attempts to access resource.

2. Resource redirects browser to STS URL.

3. Browser redirects to STS URL.

4. User authenticates to STS.

5. STS issues token to client.

6. Token is passed to resource.

7. User is granted access to resource.

3.7.2.2.1. Active Client Flow

1. Username used to request CBA token.

2. STS authenticates user.

3. CBA token issues to application.

4. Call made to web service using token.

5. WIF validates security token.

6. Response returned.

3.7.3. Cross-Realm Federation with CBA

As we’ve seen, each application must be configured with an issuer. This issuer is the one that creates the tokens that will be trusted by the application. So what happens when an application trusts one issuer but a user logs into a different issuer? How can the user still use the application? The answer is cross-realm federation.

Cross-realm federation allows you to log into one STS and access applications that are configured for another STS. There are many situations where this might be the case. You might have a situation where you have an application that is accessed by customers or partners, but you don’t want to manage user accounts for those users. You can have the users log into a separate IdP but still allow them access to your application. You may also have a situation where your organization has acquired a new company. This company already had their own IdP. If you need to provide these users access to your company’s applications, you don’t have to wait until you port all the users over to your IdP. They can still log into their own IdP and have access to your company’s applications.

You can set up a federation trust between two issuers. In addition to configuring the trust, you have to configure a token translation. With a token translation, you configure the incoming claim and what the outbound claim should be changed to.

1. User attempts to access application.

2. User is redirected to issuer1 configured on application.

3. User selects issuer2 for authentication.

4. User authenticates to issuer2 and receives token.

5. User presents token to issuer1.

6. Issuer1 converts token to one that can be used by applications and send that token to user.

7. User presents new token to application.

MS 문서 https://www.google.co.kr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&sqi=2&ved=0CDQQFjAA&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F7%2Fd%2F0%2F7d0b5166-6a8a-418a-addd-95ee9b046994%2FGeneva_Beta1_DataSheet.pdf&ei=XuSxUYuUAYWbigeJiYGIAg&usg=AFQjCNGbmhiqxvwNx-T4OKxVL5gVApVAZA&sig2=QPNpHxknVD6NHYHVVHCeBw&bvm=bv.47534661,d.aGc 

에 설명 엄청 잘되어 있음

MS에서는 WIF (Windows Identity Foundation) - .NET Framework과 ADFS 2.0(서버)를 이용해서 구현