[security-dev] Entitlement versus Enforcement Model

[Bill Burke]

On 11/7/2012 4:02 PM, Anil Saldhana wrote:
> On 11/07/2012 02:44 PM, Bill Burke wrote:
>>
>> On 11/7/2012 3:28 PM, Anil Saldhana wrote:
>>> On 11/07/2012 01:21 PM, Bill Burke wrote:
>>>> I'm working on prototype/protocol that combines client-cert and signed
>>>> tokens.
>>>>
>>>> Token is signed by the IDP and contains:
>>>> * user identity
>>>> * roles/permissions
>>>> * expiration/timestamp
>>> Bill,  this translates to a SAML Response from an IDP that contains
>>> Authentication Statement (who the user is, who issued the assertion,
>>> public key of the IDP etc) and attribute Statements (roles/permissions
>>> can be viewed as attributes an identity has).
>>> If we can somehow translate this entire thing into a JSON construct, it
>>> will be lightweight and cool.
>>>
>> Translating all the verbose nonsense contained in SAML documents to the
>> much simpler domain of Java EE role-based model is something you'll have
>> to do anyways.  You probably have *already* it. :)
>>
>> What I want to see happen is ditching SAML entirely for a very tight
>> token format that is as small as possible.  If you follow this route,
>> you can include signed tokens within URLs (Will work great with OAuth2).
>>     SAML documents are just WAY too big for these types of redirection
>> protocols.
>>
>> IMO, SAML is ridiculous.  All the metadata a service needs in an
>> authenticated request is really userid, permission metadata, and maybe a
>> URL that references the full information about that user.  If the
>> service wants information like first/last name, email, etc., it can
>> query this URL and negotiate the desired format using HTTP.
> Bill - what I am proposing is a JSON structure that is in the worst case
> the full translation of a SAML structure. SAML can be daunting because
> it tries to solve everything for everybody and your usecases may not
> warrant all the goodies that come with SAML.

I think JWT already defines much of the crucial metadata that SAML 
provides (expiration, timestamp, etc.).  As far as user metadata, see my 
URL-based approach.

> But the JWT work going on in IETF lacks in the richness of SAML
> structures, if someone desires it.

IMO, instead of defining one uber-format, define media types per use 
cases.  JWS (Json web signature) has a content-type header that allows 
you to specify the type of the encoded data.  What you could do is add a 
negotiation protocol for this or just provide a callback URL for the 
service so it can obtain a more rich token format it desires.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com