As a vendor we can't really share deployment particulars of our customers. But we've had product support for the SAML authorization grant for some time now. So I can point to some online documentation for the support we provide in our PingFederate product as an AS, http://documentation.pingidentity.com/display/PF610/Configuring+an+OAuth+SAML+Grant+IdP+Connectionand http://documentation.pingidentity.com/display/PF610/Grant+Types#GrantTypes-1218708as well client side support for obtaining suitable SAML tokens via WS-Trust or brokering the OAuth request directly to the AS, http://documentation.pingidentity.com/display/PF610/STS+OAuth+Integration
Off hand I also remember that Google released some support for JWT grants in March. My colleague, the venerable John Fontana, wrote about that on ZDnet, http://www.zdnet.com/blog/identity/google-dumps-keys-passwords-secures-services-with-standards-certs/342 On Mon, Oct 8, 2012 at 6:14 PM, Chuck Mortimore <cmortim...@salesforce.com>wrote: > Our use-cases are pretty straightforward - customers want to perform > server to server integration tasks without passwords. > > We use the SAML and JWT assertion profiles to enable them to authenticate > to our system without having a password for the service principal they're > trying to act as. Sometimes this is for security purposes ( customer > doesn't want to use passwords ), and sometimes it's for scale purposes ( > customer is building some sort of hub-spoke integration architecture where > passwords and their associated distribution and maintenance simple won't > scale ) > > While SAML is predominantly used for Web SSO today, it is used and quite > applicable in these types of scenarios. The easy way to picture what > we're doing is deploying a Security Token Service similar to WS-Trust, but > without all the baggage of WS-Trust....you can simply post Assertions to > our Token Endpoint and we can exchange that for oauth access tokens. > > -cmort > > > On Oct 8, 2012, at 5:05 PM, Mike Jones wrote: > > Yes, OpenID Connect uses the Assertions spec and the JWT Assertion > Profile. See uses of [OAuth.JWT] in > http://openid.net/specs/openid-connect-messages-1_0.html. It is used > for both client_secret_jwt and private_key_jwt client authentication. Per > http://osis.idcommons.net/wiki/Category:OC4_Solution, there are a dozen > publicly declared OpenID Connect implementations (admittedly some > incomplete), and substantial interop testing is under way, per > http://osis.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4.**** > ** ** > Brian Campbell and Chuck Mortimore may be able to provide similar data for > use of the SAML Profile.**** > ** ** > -- Mike*** > * > ** ** > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On > Behalf Of *Tschofenig, Hannes (NSN - FI/Espoo) > *Sent:* Monday, October 08, 2012 5:13 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] draft-ietf-oauth-assertions-06**** > ** ** > > Hi all,**** > > I took a look at version -06 of the assertions draft to see whether some > of the discussions had been reflected in this recent draft update.**** > > I was hoping that there is a bit more explanation of the use case that > motivates the work. Unfortunately, the update does not contain anything > along these lines.**** > > For example, the use cases could clarify the following aspects:**** > > · Why we need these new client authentication mechanisms? This is > not necessarily a way in which SAML is used (at least not to my knowledge). > If I understood it correctly then the new client authentication > mechanism is only used between the client and the authorization server but > not with the resource server. Did I correctly read the document? **** > > · Then, there is the assertion usage for authorization grants. > There, one could argue that the use case is to interwork with existing SAML > infrastructure. The sameargument does not apply for the JSON based format > since there is no transition need (IMHO at least).**** > > Ciao > Hannes**** > > PS: For the shepherd write-up I have to attach information about the > implementation and deployment experience. Is there anything I could > mention? Has this specification been part of the OpenID Connect interop > tests? If so, what specifically had been tested?**** > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
