Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Participant name and logoContact names/emailsSolution full nameSolution abbrevRoles (AS, RS, C)
Gluu (logo, handle)
Mike Schwartz: mike-at-gluu.org
Yuriy Zabrovarnayy: yuriy-at-gluu.org
OXAuthOXAS, RS, C
Apache pluginAPRS, C
Cloud Identity Limited, (logo, handle)Maciej Machulak: maciej.machulak(AT)cloudidentity.co.ukNuveAMCIAS, RS, C
  Python/Java UMAPURS, C
Roland HedbergRoland Hedberg: roland.hedberg-at-adm.umu.sePyUMARHAS, RS, C
ZXID.orgSampo Kellomäki: sampo-uma14-at-zxid.orgZXID w/mod_auth_samlZXAS, RS, C

Solution information: AS role

It is recommended that the AS provide RO and RqP login credentials that can be used in a programmatic fashion, e.g. in a simple HTML form. It is assumed that the C is clientclaims-unaware and will be using the redirect claim profile to redirect the RqP to the AS for login as the sole claims-gathering process. The "Alice" user can be used as both an RO and an RqP. The "Bob" user can be used as an RqP. The different RqPs can be used with the same client to test policies that discriminate between RqPs using the same client. Clients "A" and "B" can be easily used to test policies that discriminate between the same RqP using different clients.

Solution:roleConfig data URLLogin credentials for RO and RqPToken strings for "Alice" and "Bob" usersStatic credentials for client "A" and client "B"Supports dynamic client registration for RS and C?Other details
OX:AShttps://seed.gluu.org/.well-known/uma-configuration

Alice:

Bob:

 RS: yes, C: yes

See:

CI:AShttps://demo.nuveam.com/.well-known/uma-configuration

Alice:

Bob:

 RS: yes, C: yes

Product Website, Online Demo

RH:AS 

Alice:

Bob:

   
ZX:AShttps://zxidp.org/.well-known/uma-configurationtest:test or HTTPS client cert or SAML IdP https://zxidp.org/idp with test:test RS: yes, C: yeshttps://zxidp.org/umainfo.html

Solution information: RS role

...

Solution:roleAPI infoSDK avail?Login URL and RO creds/token/session detailsProtected resource URL(s) infoClient SDK/library infoExpects dynamic client registration at AS?Other details
OX:RSJavahttps://seed.gluu.org/oxuma-rs/

https://seed.gluu.org/oxuma-rs/ws/phone

CRUD:
1. GET (view phones) : protected by "view" or "all" scope
2. DELETE (remove phone) : protected by "remove" or "all" scope
3. PUT (create/update phone) : protected by "add" or "all" scope

Scopes:
http://seed.gluu.org/oxuma-rs/ws/scope/add
http://seed.gluu.org/oxuma-rs/ws/scope/view
http://seed.gluu.org/oxuma-rs/ws/scope/all
http://seed.gluu.org/oxuma-rs/ws/scope/remove

   
CI:RShttps://nuvepds.appspot.com/about/apiPython and Javahttps://nuvepds.appspot.com (Sign in with your social profile)https://nuvepds.appspot.com/about/api Optional 
RH:RSUses "pbryan" (http-json-resource) https://xenosmilus.umdc.umu.se:8777/login.html (user:alice, password:krall)Base URL for alice's resources: https://xenosmilus.umdc.umu.se:8777/json/aliceAvailable in Python and Java (sample at https://nuvepdsclient.appspot.com/) – where? Supports webfinger. Supports acct and http identifier urls.
ZX:RShttps://zxidp.org/umainfo.htmllibzxid (C/C++, PHP, Perl, Java, Apache httpd module)     

Solution information: C role

As noted above, it is assumed that the C is clientclaims-unaware and will be using the redirect claim profile to redirect the RqP to the AS for login as the sole claims-gathering process for assessing policy. There are currently (V0.9) not even any optional feature tests for claim profiles anyway, so we're not testing claims gathering at this stage.

Solution:roleApp typeOther details
OX:Chttps://seed.gluu.org/oxuma-rp/ 
CI:Chttps://nuvepdsclient.appspot.com/Sign in using social profile or pass a token
RH:C  
ZX:C