Thanks guys. > 1) What will be added to the REST request when Ping is being used? > 2) How will that be validated? Callback to ping? Cryptographically? > 3) How do you see group membership being obtained when Ping is used for > SSO?
So far we used Ping to authenticate browser based access. In this case, Ping drops a cookie which contains the user's authentication information. In our case, we have the group information on the servers using ldap. The Authentication works via browsers redirects and information is shared using cookies. The information in cookie is encrypted using a secret shared between Ping and servers. I am trying to get more details on how to use Ping in non-browser usecase. I am assuming , the knox usage is primary non-browser based. Once I get these details and based on inputs from you, I'll add a the design proposal to the jira. thanks, benoy ________________________________ From: Dilli Arumugam [[email protected]] Sent: Tuesday, November 19, 2013 10:27 PM To: [email protected] Cc: Benoy Antony Subject: Re: Knox with Ping Welcome Benoy. Thanks Dilli On Tue, Nov 19, 2013 at 8:31 PM, larry mccay <[email protected]<mailto:[email protected]>> wrote: Hi Benoy - Great to hear that you are interested in taking on KNOX-192! I think Kevin's questions are a great start. * I think that we have to determine how generic a solution it is either across providers or even across Ping products. I know that there is a Ping Federate in addition to other solutions. Are you proposing a solution that would integrate with one or more of these and can we find out specifically? * I also assume that we are talking about consuming a token that was the result of a previous Ping based authentication - not that we will be collecting credentials and authenticating against Ping. If this is correct, we are really talking about a federation provider rather than an authentication provider. This distinction is mostly informational and we may collapse the two into a security provider type at some point. * I think that updating the Jira with some of these details as an introduction to a proposal that answers Kevin's questions would be great. In terms of what the module will need to consist of - you can use gateway-provider-security-shiro as an example of an authentication provider. The central component for a security provider is the servlet filter that does the processing/validation of the identity token. We can talk through the other components in the shiro provider as needed in order to spin up a proper Ping provider. This process will also be great to derive documentation for developing provider from! Looking forward to your contribution, Benoy. thanks, --larry On Tue, Nov 19, 2013 at 10:57 PM, Kevin Minder <[email protected]<mailto:[email protected]> > wrote: > Hey Benoy, > Glad you have some time to get this going. Lets continue this > conversation on dev@knox. I'm guessing you are asking about which module > this should go in. My thinking is that this would go in a separate module > probably called gateway-provider-security-ping or something similar. If > after some quick discussion that is the right answer I'd be happy to create > a skeleton for you. We should start though with getting an understanding > of how to approach the Ping integration. To start with I have questions > like: > 1) What will be added to the REST request when Ping is being used? > 2) How will that be validated? Callback to ping? Cryptographically? > 3) How do you see group membership being obtained when Ping is used for > SSO? > 4) Other things that I hope Larry will be able to think of... > Kevin. > > > On 11/19/13 10:49 PM, Benoy Antony wrote: > >> Larry, Kevin, >> >> hope you are keeping fine. >> If its appropriate, I can take up https://issues.apache.org/ >> jira/browse/KNOX-192 as I have some bandwidth now. >> >> I have the new master version of knox and have the eclipse workspace >> based on it. If I can take up this task, could you please let me know which >> project should have this integration code ? >> >> thanks , >> Benoy >> >> > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity > to which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. > CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
