[security-dev] Entitlement versus Enforcement Model
Anil.Saldhana at redhat.com
Wed Nov 7 16:02:49 EST 2012
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
>>> 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
> 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.
But the JWT work going on in IETF lacks in the richness of SAML
structures, if someone desires it.
> To integrate with existing SAML based solutions, is there any reason an
> IDM Proxy couldn't be written that is a bridge between this simple token
> protocol and the SAML-based third-party?
More information about the security-dev