I have been saying for a while that I need to raise a discussion regarding the verification of Digest based requests against an IdentityManager. At the moment this is predominantly needed for Undertow although there is also a need for same with SASL. The following document describes the proposed use of the Undertow IdentityManager API and the requirement for the implementation i.e. what we would need from PicketLink IDM once wrapped in the WildFly integration: - https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... The three methods on the IdentityManager interface previously used for Digest based authentication will all be removed. An identity manager that can provide this capability will also be compatible with SASL based authentication without needing to be aware of the actual verification requirements within SASL. Regards, Darran Lofthouse. _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

As there is going to be an integration layer between Undertow and PicketLink IDM I think the main requirement for PicketLink IDM is going to be: - - Where PLIDM has access to plain text passwords for a specified account and using the specified digest algorithm generate the digest for the username, realm and password separated by colons. - Where PLIDM is storing pre-prepared digests for a specified account look up the pre-prepared username, realm, password digest for the algorithm specified. This latter option relates to something I brought up a while ago where a single credential could be associated with an account in a number of different formats - what this means is that the Digest algorithms can potentially go beyond MD5 to use stronger digest algorithms. The pre-prepared digests do offer some protection but PLIDM would still be responsible for storing them securely to provide protection against accidental disclosure. The most important thing however is that we do not need the plain text passwords to be passed onto the Undertow or SASL classes handling the actual authentication. Regards, Darran Lofthouse. On 30/04/13 12:56, Shane Bryzak wrote: > Looks pretty straight forward - what do you need from the PicketLink > side for this? The PLIDM implementation should be quite simple, I can > help out with it if required. > > Shane > > On 30/04/13 19:24, Darran Lofthouse wrote: >> I have been saying for a while that I need to raise a discussion >> regarding the verification of Digest based requests against an >> IdentityManager. >> >> At the moment this is predominantly needed for Undertow although there >> is also a need for same with SASL. >> >> The following document describes the proposed use of the Undertow >> IdentityManager API and the requirement for the implementation i.e. what >> we would need from PicketLink IDM once wrapped in the WildFly integration: - >> >> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... >> >> The three methods on the IdentityManager interface previously used for >> Digest based authentication will all be removed. >> >> An identity manager that can provide this capability will also be >> compatible with SASL based authentication without needing to be aware of >> the actual verification requirements within SASL. >> >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Disregard my previous email. After looking at your linked code Shane, and reviewing the email thread I had with you guys awhile back, I realize why you have what you have. Thanks for your patience! BTW, maybe Undertow should reconsider using Picketlink IDM API directly. You might end up implementing the same thing and that would be a shame. Don't you think Picketlink could be refactored enough to reduce dependencies? On 4/30/2013 8:58 AM, Shane Bryzak wrote: > What PicketLink stores for digests is the latter [1] (in no situation do > we ever store plain text passwords). There are essentially two methods > for validating and managing credentials in the IdentityManager [2] > (three if you count one extra overloaded method): > > void validateCredentials(Credentials credentials); > void updateCredential(Agent agent, Object credential); > > There is no API method for retrieving an actual credential value so by > design credential storage is quite secure. > > To briefly summarise how things work for a digest authentication in > PicketLink; we would pass in an instance of DigestCredentials [3] to the > IdentityManager.validateCredentials() method, which is essentially a > wrapper around a Digest [4] (which should look quite familiar). The > actual implementation of the validation logic can be found in > DigestCredentialHandler [5]. > > > [1] > https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... > [2] > https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... > [3] > https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... > [4] > https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... > [5] > https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... > > Shane > > On 30/04/13 22:26, Darran Lofthouse wrote: >> As there is going to be an integration layer between Undertow and >> PicketLink IDM I think the main requirement for PicketLink IDM is going >> to be: - >> >> - Where PLIDM has access to plain text passwords for a specified >> account and using the specified digest algorithm generate the digest for >> the username, realm and password separated by colons. >> >> - Where PLIDM is storing pre-prepared digests for a specified account >> look up the pre-prepared username, realm, password digest for the >> algorithm specified. >> >> This latter option relates to something I brought up a while ago where a >> single credential could be associated with an account in a number of >> different formats - what this means is that the Digest algorithms can >> potentially go beyond MD5 to use stronger digest algorithms. >> >> The pre-prepared digests do offer some protection but PLIDM would still >> be responsible for storing them securely to provide protection against >> accidental disclosure. The most important thing however is that we do >> not need the plain text passwords to be passed onto the Undertow or SASL >> classes handling the actual authentication. >> >> Regards, >> Darran Lofthouse. >> >> >> On 30/04/13 12:56, Shane Bryzak wrote: >>> Looks pretty straight forward - what do you need from the PicketLink >>> side for this? The PLIDM implementation should be quite simple, I can >>> help out with it if required. >>> >>> Shane >>> >>> On 30/04/13 19:24, Darran Lofthouse wrote: >>>> I have been saying for a while that I need to raise a discussion >>>> regarding the verification of Digest based requests against an >>>> IdentityManager. >>>> >>>> At the moment this is predominantly needed for Undertow although there >>>> is also a need for same with SASL. >>>> >>>> The following document describes the proposed use of the Undertow >>>> IdentityManager API and the requirement for the implementation i.e. what >>>> we would need from PicketLink IDM once wrapped in the WildFly integration: - >>>> >>>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... >>>> >>>> The three methods on the IdentityManager interface previously used for >>>> Digest based authentication will all be removed. >>>> >>>> An identity manager that can provide this capability will also be >>>> compatible with SASL based authentication without needing to be aware of >>>> the actual verification requirements within SASL. >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> _______________________________________________ >>>> security-dev mailing list >>>> security-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >>> >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > > > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

What PicketLink stores for digests is the latter [1] (in no situation do we ever store plain text passwords). There are essentially two methods for validating and managing credentials in the IdentityManager [2] (three if you count one extra overloaded method): void validateCredentials(Credentials credentials); void updateCredential(Agent agent, Object credential); There is no API method for retrieving an actual credential value so by design credential storage is quite secure. To briefly summarise how things work for a digest authentication in PicketLink; we would pass in an instance of DigestCredentials [3] to the IdentityManager.validateCredentials() method, which is essentially a wrapper around a Digest [4] (which should look quite familiar). The actual implementation of the validation logic can be found in DigestCredentialHandler [5]. [1] https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... [2] https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... [3] https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... [4] https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... [5] https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... Shane On 30/04/13 22:26, Darran Lofthouse wrote: > As there is going to be an integration layer between Undertow and > PicketLink IDM I think the main requirement for PicketLink IDM is going > to be: - > > - Where PLIDM has access to plain text passwords for a specified > account and using the specified digest algorithm generate the digest for > the username, realm and password separated by colons. > > - Where PLIDM is storing pre-prepared digests for a specified account > look up the pre-prepared username, realm, password digest for the > algorithm specified. > > This latter option relates to something I brought up a while ago where a > single credential could be associated with an account in a number of > different formats - what this means is that the Digest algorithms can > potentially go beyond MD5 to use stronger digest algorithms. > > The pre-prepared digests do offer some protection but PLIDM would still > be responsible for storing them securely to provide protection against > accidental disclosure. The most important thing however is that we do > not need the plain text passwords to be passed onto the Undertow or SASL > classes handling the actual authentication. > > Regards, > Darran Lofthouse. > > > On 30/04/13 12:56, Shane Bryzak wrote: >> Looks pretty straight forward - what do you need from the PicketLink >> side for this? The PLIDM implementation should be quite simple, I can >> help out with it if required. >> >> Shane >> >> On 30/04/13 19:24, Darran Lofthouse wrote: >>> I have been saying for a while that I need to raise a discussion >>> regarding the verification of Digest based requests against an >>> IdentityManager. >>> >>> At the moment this is predominantly needed for Undertow although there >>> is also a need for same with SASL. >>> >>> The following document describes the proposed use of the Undertow >>> IdentityManager API and the requirement for the implementation i.e. what >>> we would need from PicketLink IDM once wrapped in the WildFly integration: - >>> >>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... >>> >>> The three methods on the IdentityManager interface previously used for >>> Digest based authentication will all be removed. >>> >>> An identity manager that can provide this capability will also be >>> compatible with SASL based authentication without needing to be aware of >>> the actual verification requirements within SASL. >>> >>> Regards, >>> Darran Lofthouse. >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Sent my last message using the wrong account so it may arrive but writing again just in case. The Digest Credential is what we need stored but we would potentially need more than one to be stored to cope with different hash algorithms being used. The issue regarding what is currently in PicketLink is that it is causing HTTP specific aspects of Digest authentication to leak into the IDM and at the same time is only implementing a small subset of the RFC2617 specification. We need access to the same pre-prepared digests for SASL authentication but this is using a slightly different format for the digests that are compared. In addition to this we need the entire messages being exchanged both inbound and outbound to be digested along with these pre-prepared hashes for the purpose of adding integrity protection for the messages exchanged. There is also a middle ground of providing an appropriate header so that the server can also prove it knows the clients password. This is why we need access to the pre-prepared digest for the chosen algorithm or at the very least an option to request PLIDM pushed it into a MessageDigest instance (Maybe PLIDM provides the MessageDigest and wraps it). Otherwise there is going to be a lot of HTTP specific and SASL specific code to potentially push into an IDM and the IDM is going to have to be much more involved in the actual message exchanges. Regards, Darran Lofthouse. On 30/04/13 13:58, Shane Bryzak wrote: > What PicketLink stores for digests is the latter [1] (in no situation do > we ever store plain text passwords). There are essentially two methods > for validating and managing credentials in the IdentityManager [2] > (three if you count one extra overloaded method): > > void validateCredentials(Credentials credentials); > void updateCredential(Agent agent, Object credential); > > There is no API method for retrieving an actual credential value so by > design credential storage is quite secure. > > To briefly summarise how things work for a digest authentication in > PicketLink; we would pass in an instance of DigestCredentials [3] to the > IdentityManager.validateCredentials() method, which is essentially a > wrapper around a Digest [4] (which should look quite familiar). The > actual implementation of the validation logic can be found in > DigestCredentialHandler [5]. > > > [1] > https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... > [2] > https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... > [3] > https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... > [4] > https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... > [5] > https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... > > Shane > > On 30/04/13 22:26, Darran Lofthouse wrote: >> As there is going to be an integration layer between Undertow and >> PicketLink IDM I think the main requirement for PicketLink IDM is going >> to be: - >> >> - Where PLIDM has access to plain text passwords for a specified >> account and using the specified digest algorithm generate the digest for >> the username, realm and password separated by colons. >> >> - Where PLIDM is storing pre-prepared digests for a specified account >> look up the pre-prepared username, realm, password digest for the >> algorithm specified. >> >> This latter option relates to something I brought up a while ago where a >> single credential could be associated with an account in a number of >> different formats - what this means is that the Digest algorithms can >> potentially go beyond MD5 to use stronger digest algorithms. >> >> The pre-prepared digests do offer some protection but PLIDM would still >> be responsible for storing them securely to provide protection against >> accidental disclosure. The most important thing however is that we do >> not need the plain text passwords to be passed onto the Undertow or SASL >> classes handling the actual authentication. >> >> Regards, >> Darran Lofthouse. >> >> >> On 30/04/13 12:56, Shane Bryzak wrote: >>> Looks pretty straight forward - what do you need from the PicketLink >>> side for this? The PLIDM implementation should be quite simple, I can >>> help out with it if required. >>> >>> Shane >>> >>> On 30/04/13 19:24, Darran Lofthouse wrote: >>>> I have been saying for a while that I need to raise a discussion >>>> regarding the verification of Digest based requests against an >>>> IdentityManager. >>>> >>>> At the moment this is predominantly needed for Undertow although there >>>> is also a need for same with SASL. >>>> >>>> The following document describes the proposed use of the Undertow >>>> IdentityManager API and the requirement for the implementation i.e. what >>>> we would need from PicketLink IDM once wrapped in the WildFly integration: - >>>> >>>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... >>>> >>>> The three methods on the IdentityManager interface previously used for >>>> Digest based authentication will all be removed. >>>> >>>> An identity manager that can provide this capability will also be >>>> compatible with SASL based authentication without needing to be aware of >>>> the actual verification requirements within SASL. >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> _______________________________________________ >>>> security-dev mailing list >>>> security-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >>> >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > > > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Alternatively - could I plug-in my own Credential types and a corresponding CredentialHandler for them? On 30/04/13 14:47, Darran Lofthouse wrote: > Sent my last message using the wrong account so it may arrive but > writing again just in case. > > The Digest Credential is what we need stored but we would potentially > need more than one to be stored to cope with different hash algorithms > being used. > > The issue regarding what is currently in PicketLink is that it is > causing HTTP specific aspects of Digest authentication to leak into the > IDM and at the same time is only implementing a small subset of the > RFC2617 specification. We need access to the same pre-prepared digests > for SASL authentication but this is using a slightly different format > for the digests that are compared. > > In addition to this we need the entire messages being exchanged both > inbound and outbound to be digested along with these pre-prepared hashes > for the purpose of adding integrity protection for the messages > exchanged. There is also a middle ground of providing an appropriate > header so that the server can also prove it knows the clients password. > > This is why we need access to the pre-prepared digest for the chosen > algorithm or at the very least an option to request PLIDM pushed it into > a MessageDigest instance (Maybe PLIDM provides the MessageDigest and > wraps it). > > Otherwise there is going to be a lot of HTTP specific and SASL specific > code to potentially push into an IDM and the IDM is going to have to be > much more involved in the actual message exchanges. > > Regards, > Darran Lofthouse. > > > On 30/04/13 13:58, Shane Bryzak wrote: >> What PicketLink stores for digests is the latter [1] (in no situation do >> we ever store plain text passwords). There are essentially two methods >> for validating and managing credentials in the IdentityManager [2] >> (three if you count one extra overloaded method): >> >> void validateCredentials(Credentials credentials); >> void updateCredential(Agent agent, Object credential); >> >> There is no API method for retrieving an actual credential value so by >> design credential storage is quite secure. >> >> To briefly summarise how things work for a digest authentication in >> PicketLink; we would pass in an instance of DigestCredentials [3] to the >> IdentityManager.validateCredentials() method, which is essentially a >> wrapper around a Digest [4] (which should look quite familiar). The >> actual implementation of the validation logic can be found in >> DigestCredentialHandler [5]. >> >> >> [1] >> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >> [2] >> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >> [3] >> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >> [4] >> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >> [5] >> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >> >> Shane >> >> On 30/04/13 22:26, Darran Lofthouse wrote: >>> As there is going to be an integration layer between Undertow and >>> PicketLink IDM I think the main requirement for PicketLink IDM is going >>> to be: - >>> >>> - Where PLIDM has access to plain text passwords for a specified >>> account and using the specified digest algorithm generate the digest for >>> the username, realm and password separated by colons. >>> >>> - Where PLIDM is storing pre-prepared digests for a specified account >>> look up the pre-prepared username, realm, password digest for the >>> algorithm specified. >>> >>> This latter option relates to something I brought up a while ago where a >>> single credential could be associated with an account in a number of >>> different formats - what this means is that the Digest algorithms can >>> potentially go beyond MD5 to use stronger digest algorithms. >>> >>> The pre-prepared digests do offer some protection but PLIDM would still >>> be responsible for storing them securely to provide protection against >>> accidental disclosure. The most important thing however is that we do >>> not need the plain text passwords to be passed onto the Undertow or SASL >>> classes handling the actual authentication. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> On 30/04/13 12:56, Shane Bryzak wrote: >>>> Looks pretty straight forward - what do you need from the PicketLink >>>> side for this? The PLIDM implementation should be quite simple, I can >>>> help out with it if required. >>>> >>>> Shane >>>> >>>> On 30/04/13 19:24, Darran Lofthouse wrote: >>>>> I have been saying for a while that I need to raise a discussion >>>>> regarding the verification of Digest based requests against an >>>>> IdentityManager. >>>>> >>>>> At the moment this is predominantly needed for Undertow although there >>>>> is also a need for same with SASL. >>>>> >>>>> The following document describes the proposed use of the Undertow >>>>> IdentityManager API and the requirement for the implementation i.e. what >>>>> we would need from PicketLink IDM once wrapped in the WildFly integration: - >>>>> >>>>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... >>>>> >>>>> The three methods on the IdentityManager interface previously used for >>>>> Digest based authentication will all be removed. >>>>> >>>>> An identity manager that can provide this capability will also be >>>>> compatible with SASL based authentication without needing to be aware of >>>>> the actual verification requirements within SASL. >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> _______________________________________________ >>>>> security-dev mailing list >>>>> security-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/security-dev >>>> _______________________________________________ >>>> security-dev mailing list >>>> security-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev >>>> >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >> >> >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

So you're saying that instead of doing straightforward code to get at information stored within the IDM to perform a hash a full request or response, he has to hack a handler to do it through a verify() call? Would it be the same if I wanted to sign/encrypt an arbitrary set of bytes with a private key/secret stored in the IDM? I'd have to hack a verifier to tunnel this? I thought we were rewriting these security APIs so that we didn't have to do stupid pet tricks anymore? On 4/30/2013 4:12 PM, Shane Bryzak wrote: > Yes, you can absolutely do this. > > > On 30/04/13 23:56, Darran Lofthouse wrote: >> Alternatively - could I plug-in my own Credential types and a >> corresponding CredentialHandler for them? >> >> On 30/04/13 14:47, Darran Lofthouse wrote: >>> Sent my last message using the wrong account so it may arrive but >>> writing again just in case. >>> >>> The Digest Credential is what we need stored but we would potentially >>> need more than one to be stored to cope with different hash algorithms >>> being used. >>> >>> The issue regarding what is currently in PicketLink is that it is >>> causing HTTP specific aspects of Digest authentication to leak into the >>> IDM and at the same time is only implementing a small subset of the >>> RFC2617 specification. We need access to the same pre-prepared digests >>> for SASL authentication but this is using a slightly different format >>> for the digests that are compared. >>> >>> In addition to this we need the entire messages being exchanged both >>> inbound and outbound to be digested along with these pre-prepared hashes >>> for the purpose of adding integrity protection for the messages >>> exchanged. There is also a middle ground of providing an appropriate >>> header so that the server can also prove it knows the clients password. >>> >>> This is why we need access to the pre-prepared digest for the chosen >>> algorithm or at the very least an option to request PLIDM pushed it into >>> a MessageDigest instance (Maybe PLIDM provides the MessageDigest and >>> wraps it). >>> >>> Otherwise there is going to be a lot of HTTP specific and SASL specific >>> code to potentially push into an IDM and the IDM is going to have to be >>> much more involved in the actual message exchanges. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> On 30/04/13 13:58, Shane Bryzak wrote: >>>> What PicketLink stores for digests is the latter [1] (in no situation do >>>> we ever store plain text passwords). There are essentially two methods >>>> for validating and managing credentials in the IdentityManager [2] >>>> (three if you count one extra overloaded method): >>>> >>>> void validateCredentials(Credentials credentials); >>>> void updateCredential(Agent agent, Object credential); >>>> >>>> There is no API method for retrieving an actual credential value so by >>>> design credential storage is quite secure. >>>> >>>> To briefly summarise how things work for a digest authentication in >>>> PicketLink; we would pass in an instance of DigestCredentials [3] to the >>>> IdentityManager.validateCredentials() method, which is essentially a >>>> wrapper around a Digest [4] (which should look quite familiar). The >>>> actual implementation of the validation logic can be found in >>>> DigestCredentialHandler [5]. >>>> >>>> >>>> [1] >>>> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >>>> [2] >>>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>>> [3] >>>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>>> [4] >>>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>>> [5] >>>> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >>>> >>>> Shane >>>> >>>> On 30/04/13 22:26, Darran Lofthouse wrote: >>>>> As there is going to be an integration layer between Undertow and >>>>> PicketLink IDM I think the main requirement for PicketLink IDM is going >>>>> to be: - >>>>> >>>>> - Where PLIDM has access to plain text passwords for a specified >>>>> account and using the specified digest algorithm generate the digest for >>>>> the username, realm and password separated by colons. >>>>> >>>>> - Where PLIDM is storing pre-prepared digests for a specified account >>>>> look up the pre-prepared username, realm, password digest for the >>>>> algorithm specified. >>>>> >>>>> This latter option relates to something I brought up a while ago where a >>>>> single credential could be associated with an account in a number of >>>>> different formats - what this means is that the Digest algorithms can >>>>> potentially go beyond MD5 to use stronger digest algorithms. >>>>> >>>>> The pre-prepared digests do offer some protection but PLIDM would still >>>>> be responsible for storing them securely to provide protection against >>>>> accidental disclosure. The most important thing however is that we do >>>>> not need the plain text passwords to be passed onto the Undertow or SASL >>>>> classes handling the actual authentication. >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On 30/04/13 12:56, Shane Bryzak wrote: >>>>>> Looks pretty straight forward - what do you need from the PicketLink >>>>>> side for this? The PLIDM implementation should be quite simple, I can >>>>>> help out with it if required. >>>>>> >>>>>> Shane >>>>>> >>>>>> On 30/04/13 19:24, Darran Lofthouse wrote: >>>>>>> I have been saying for a while that I need to raise a discussion >>>>>>> regarding the verification of Digest based requests against an >>>>>>> IdentityManager. >>>>>>> >>>>>>> At the moment this is predominantly needed for Undertow although there >>>>>>> is also a need for same with SASL. >>>>>>> >>>>>>> The following document describes the proposed use of the Undertow >>>>>>> IdentityManager API and the requirement for the implementation i.e. what >>>>>>> we would need from PicketLink IDM once wrapped in the WildFly integration: - >>>>>>> >>>>>>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... >>>>>>> >>>>>>> The three methods on the IdentityManager interface previously used for >>>>>>> Digest based authentication will all be removed. >>>>>>> >>>>>>> An identity manager that can provide this capability will also be >>>>>>> compatible with SASL based authentication without needing to be aware of >>>>>>> the actual verification requirements within SASL. >>>>>>> >>>>>>> Regards, >>>>>>> Darran Lofthouse. >>>>>>> _______________________________________________ >>>>

On 4/30/2013 4:54 PM, Shane Bryzak wrote: > There's two options here; the first one is to store the private key as > an attribute which then makes it a piece of cake to retrieve the value: > > Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret"); > PrivateKey key = attrib.getValue(); > > The other option is to implement your own CredentialHandler as mentioned > previously. The design decision to insulate the actual credential > values from the API was intentional, and at the moment the only time > they are exposed to the API is when they are created for the very first > time. With there seemingly being a major password hack on the news > every week it is in our best interest to reduce the number of attack > vectors that make this kind of thing possible, hence the decoupled > design. Think about what you're saying here.... The credential isn't protected at all because the code that is invoking the validation already has the credential. Its just not verified. For two-way SSL its even more pointless because you're validating the client with public certificates.

There's also certain credentials, i.e. a TOTP secret key, in which the credential can't be stored as a hash. So, isn't it possible for a malicious programmer to register a malicious Handler so they can get access to whatever information they want?

I guess I'm back to suggesting that anything should be queryable that's stored in the IDM. I do remember your chained IDM usecase, maybe instead of a validation() API a visitor API would be better? public interface IDM { void accept(IdmVisitor visitor); } public interface IdmVisitor { void visit(SecurityContext context, IdentityStore store); } Then somebody could still do whatever they wanted and be aware of the chaining. Credential validation fits into the visitor pattern as well.

On 4/30/2013 9:53 PM, Shane Bryzak wrote: > On 01/05/13 10:38, Bill Burke wrote: >> On 4/30/2013 4:54 PM, Shane Bryzak wrote: >>> There's two options here; the first one is to store the private key as >>> an attribute which then makes it a piece of cake to retrieve the value: >>> >>> Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret"); >>> PrivateKey key = attrib.getValue(); >>> >>> The other option is to implement your own CredentialHandler as mentioned >>> previously. The design decision to insulate the actual credential >>> values from the API was intentional, and at the moment the only time >>> they are exposed to the API is when they are created for the very first >>> time. With there seemingly being a major password hack on the news >>> every week it is in our best interest to reduce the number of attack >>> vectors that make this kind of thing possible, hence the decoupled >>> design. >> Think about what you're saying here.... The credential isn't protected >> at all because the code that is invoking the validation already has the >> credential. Its just not verified. For two-way SSL its even more >> pointless because you're validating the client with public certificates. > Think about it from the perspective of an attacker who has gained access > to the API via some vulnerability (yes, this has actually happened to us > before). If they were able to simply query the credential values > directly from the IdentityManager they could start siphoning off > password hash values for later use in a dictionary attack. > If they have access to the API then they can register malicious handlers and get at the data anyways.

>> There's also certain credentials, i.e. a TOTP secret key, in which the >> credential can't be stored as a hash. So, isn't it possible for a >> malicious programmer to register a malicious Handler so they can get >> access to whatever information they want? > Being able to register a malicious handler is a totally different ball > game. If the attacker has the capability to actually add new handler > classes to an application at runtime then they effectively own the > system anyway and there's pretty much nothing we can do about it from > that point on. > So your point above is moot. If the attacker has access to the api, they can register malicious handlers, no? There's also no reason a Java SecurityManager couldn't sit in front of the API so that only certain sections of code are allowed to access the API within the app server. > Remember also that we need this abstraction layer also because not all > identity stores are even capable of storing credential values, at least > not in a form that can be queried. Take LDAP for example; in this case > we don't actually perform any credential validation logic ourselves, it > is delegated to the LDAP server itself. Plus who knows which other IDP > solutions we may wish to support in the future - with the design we have > now we separate the concern of credential management and validation from > the IdentityManager itself, and make it easily extensible via a simple > 3-method interface. > So, I guess you're up shit creek[1] if your protocol requires the credential to be hashed with any part of your request or response, which is what Darren was complaining about I think. Again, I still think you're better off being able to query for credential values. Basic Auth and other password protocols can use the Handler architecture. Protocols like Digest, OAuth1 and Amazon S3 Auth[2] would use the query API to get at the credential and fail gracefully if the IDM can't support that model.

[1] http://www.youtube.com/watch?v=2GqNstUJ3uY [2] http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

Hello all, (I am going to send my response to the thread that continued overnight in a couple of different e-mails - adding many points to one message I think will get confusing.) If we do have an API that meets our needs I am no against using it at all however at this point I am a little concerned we may be dropping into similar problems we ended up with around JAAS. i.e. we start off with simple username / password verification so a username and a credential and then we start trying to add more complex scenarios which need more workarounds and end up having capabilities restricted.

Initially my understanding was PicketLink IDM was an identity manager, what we are now starting to talk about is it becoming a general purpose authentication manager -

but we also have requirements now moving beyond the account verification step. As I mentioned before we are now going to require code related to HTTP authentication in a CredentialHandler and we are going to require code related to SASL authentication in there.

Regards, Darran Lofthouse.

On 01/05/13 09:45, Shane Bryzak wrote: > On 01/05/13 16:46, Darran Lofthouse wrote: >> but we also have requirements now moving beyond >> the account verification step. As I mentioned before we are now going >> to require code related to HTTP authentication in a CredentialHandler >> and we are going to require code related to SASL authentication in there. > You don't *have* to put HTTP or SASL specific code in the > CredentialHandler implementation itself, there are ways to avoid this. That is what I am interested in hearing about - the example I am being shown as the correct way to do this contains HTTP specific code.

I should also mention, when it comes to the authentication / validation there is actually no such thing as a digest credential - what there actually is is a response to a challenge, this response will then potentially be different for every message received from the remote client.

>> Regards, >> Darran Lofthouse. >> >> >> > [1] > http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/Ref... > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 5/1/2013 5:08 AM, Shane Bryzak wrote: > >On 01/05/13 18:56, Darran Lofthouse wrote: >> >>On 01/05/13 09:45, Shane Bryzak wrote: >>> >>>On 01/05/13 16:46, Darran Lofthouse wrote: >>>> >>>>but we also have requirements now moving beyond >>>> >>>>the account verification step. As I mentioned before we are now going >>>> >>>>to require code related to HTTP authentication in a CredentialHandler >>>> >>>>and we are going to require code related to SASL authentication in there. >>> >>>You don't*have* to put HTTP or SASL specific code in the >>> >>>CredentialHandler implementation itself, there are ways to avoid this. >> >>That is what I am interested in hearing about - the example I am being >> >>shown as the correct way to do this contains HTTP specific code. > > > >As I mentioned in my very last e-mail (which you wouldn't have read yet > >because I only hit the send button 30 seconds ago;) the Credentials > >parameter can be used to pass state back from the CredentialHandler to > >the calling code. > > >> >> >> >>I should also mention, when it comes to the authentication / validation >> >>there is actually no such thing as a digest credential - what there >> >>actually is is a response to a challenge, this response will then >> >>potentially be different for every message received from the remote client. > > > >You'll need to forgive me because my digest-fu is rusty after not having > >used it for a few years, however I don't think this should be a > >problem. If you can describe: > > > >a) the parameters that go in, > >b) the stored "secret" information that we need for the user, > >c) the processing that has to occur with a) and b), and > >d) the state that goes out, > > > >then I'm certain we can implement this as a CredentialHandler. > > Sure you can implement it. I think we've proved with JAAS that you can basically hack whatever you need. But What you're describing Shane is a hack to get around the inadequacies of the IDM API. If it is possible to pass state via the credentials object, then this credential protection you speak of is a total and utter farse that just complicates the API.

So, basically, we're going to have to write protocol-specific Credential and CredentialHandlers, correct? How will this look at deployment time? At runtime? Who registers the Handlers and the Credential->Handler mapping? The IDM Subsystem config? The domain config? The web-app config? All the above have an effect on class loader boundaries and the set up and configuration of class Modules and class loader visibility.

On 5/1/2013 5:08 AM, Shane Bryzak wrote: > On 01/05/13 18:56, Darran Lofthouse wrote: >> On 01/05/13 09:45, Shane Bryzak wrote: >>> On 01/05/13 16:46, Darran Lofthouse wrote: >>>> but we also have requirements now moving beyond >>>> the account verification step. As I mentioned before we are now going >>>> to require code related to HTTP authentication in a CredentialHandler >>>> and we are going to require code related to SASL authentication in there. >>> You don't *have* to put HTTP or SASL specific code in the >>> CredentialHandler implementation itself, there are ways to avoid this. >> That is what I am interested in hearing about - the example I am being >> shown as the correct way to do this contains HTTP specific code. > As I mentioned in my very last e-mail (which you wouldn't have read yet > because I only hit the send button 30 seconds ago ;) the Credentials > parameter can be used to pass state back from the CredentialHandler to > the calling code. > >> I should also mention, when it comes to the authentication / validation >> there is actually no such thing as a digest credential - what there >> actually is is a response to a challenge, this response will then >> potentially be different for every message received from the remote client. > You'll need to forgive me because my digest-fu is rusty after not having > used it for a few years, however I don't think this should be a > problem. If you can describe: > > a) the parameters that go in, > b) the stored "secret" information that we need for the user, > c) the processing that has to occur with a) and b), and > d) the state that goes out, > > then I'm certain we can implement this as a CredentialHandler. > Sure you can implement it. I think we've proved with JAAS that you can basically hack whatever you need. But What you're describing Shane is a hack to get around the inadequacies of the IDM API.

If it is possible to pass state via the credentials object, then this credential protection you speak of is a total and utter farse that just complicates the API.

So, basically, we're going to have to write protocol-specific Credential and CredentialHandlers, correct? How will this look at deployment time? At runtime? Who registers the Handlers and the Credential->Handler mapping? The IDM Subsystem config? The domain config? The web-app config? All the above have an effect on class loader boundaries and the set up and configuration of class Modules and class loader visibility.

Even though not handing out the credentials directly may feel more secure, I don't think it actually is, unless you have a scenario that is not covered above?

On May 1, 2013, at 5:54 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > > > On 5/1/2013 6:39 PM, Stuart Douglas wrote: >> >> Even though not handing out the credentials directly may feel more >> secure, I don't think it actually is, unless you have a scenario that is >> not covered above? > > I'll give you another one: What does IdentityManager.updateCredential() > do? Does it allow you to update a password? If so, you're saying that > its ok to change a password, but not read it from the store? > Applications cannot and should not read the password from the store via the IdentityManager API.

In the case of ldap store, the ldap store does cred operations. IDM does not have access to the cred read from the store.

In the case of databases, such facilities does not exist- for this reason, we have an spi which normal applications do not care. Only in advanced cases such as yours, do we need to deal with credential handler constructs.

As Stuart said, unless the JVM is running with a Java Security Manager, it is a Wild West. There is no real security in terms of trusted/untrusted code.

Bill, I'm going to concede defeat on this one, so congrats on a well-fought victory ;) The one saving grace with the IdentityManager is that in an EE environment it is actually wrapped by a SecuredIdentityManager, which allows for permission checks to be defined for every single IDM operation. With this in mind, it should be trivial to implement a permission check for credential retrieval that restricts it to only allow the reading of credentials for the currently authenticated user (or whatever other permission logic the developer wants). So, with that in mind I propose the following additional methods for IdentityManager: <T extends CredentialStorage> T retrieveCurrentCredential(Agent agent, Class<T> storageClass); <T extends CredentialStorage> List<T> retrieveCredentials(Agent agent, Class<T> storageClass); These will essentially delegate to the underlying CredentialStore, and if there is none (which will be the case in an LDAP-only configuration) you'll get an OperationNotSupportedException. Will this be sufficient for your requirements? Shane _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

The IDM is a user data store, and part of that user data is credentials. At some point you have to let authentication mechanisms get access to them (I know for some simple auth methods like a hashed password this is not the case as you can just query the backing store using the provided credential to see if they match, but we should not be designing for the simplest case). The CredentialHandler method still allows you to query the credentials, just in a more round about way. So far you have not given a single example where the retrieveCurrentCredential() method would allow access to a user credential, that the CredentialHandler technique would not. Can you give me any scenarios where this approach increases security, as this seems to be the premise that your argument is based on? IMHO the ability to retrieve a credential is a IDM operation, but once you also add credential validation it becomes an authentication manager as well (as I believe Darran has already said). Using the credential to pass state around is also very problematic, as there could be multiple different mechanisms that wish to use the same credential in different ways, which would mean that the credential would need to have mutable fields for all the different state these mechanisms need. I just think this approach will cause problems for the advanced cases, and does not provide any additional security. For digest this is the difference between the digest handler just grabbing the credential it needs and using it directly, vs registering a callback handler, and using the callback handler to expose information about the stored credential using mechanism specific fields in the credential. Also if another mechanism such as SASL is also using the same credentials it gets even more problematic. Do we need two different versions of the same credential stored per user, one for each implementation of CredentialHandler, or are we going to have some way of stacking credential handlers, and we just have to make sure the credential has implementation specific fields for each handler (and just hope that no third party wants to use the same credential classes with different state). I'm sure we could hack around all these problems, and I must admit I have not spent nearly as much time working on this as you guys, but it just seems like this approach will make it more difficult to extend the available authentication mechanisms than it needs to be. Stuart Anil Saldhana wrote: > Shane - you can add the API for this. But I would like to think about it further. I really do not like creds via IM interface. > > On May 1, 2013, at 7:33 PM, Shane Bryzak&lt;sbryzak(a)redhat.com&gt; wrote: > >> Bill, I'm going to concede defeat on this one, so congrats on a >> well-fought victory ;) The one saving grace with the IdentityManager is >> that in an EE environment it is actually wrapped by a >> SecuredIdentityManager, which allows for permission checks to be defined >> for every single IDM operation. With this in mind, it should be trivial >> to implement a permission check for credential retrieval that restricts >> it to only allow the reading of credentials for the currently >> authenticated user (or whatever other permission logic the developer wants). >> >> So, with that in mind I propose the following additional methods for >> IdentityManager: >> >> <T extends CredentialStorage> T retrieveCurrentCredential(Agent >> agent, Class<T> storageClass); >> <T extends CredentialStorage> List<T> retrieveCredentials(Agent >> agent, Class<T> storageClass); >> >> These will essentially delegate to the underlying CredentialStore, and >> if there is none (which will be the case in an LDAP-only configuration) >> you'll get an OperationNotSupportedException. >> >> Will this be sufficient for your requirements? >> >> Shane >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

The IDM is a user data store, and part of that user data is credentials. At some point you have to let authentication mechanisms get access to them (I know for some simple auth methods like a hashed password this is not the case as you can just query the backing store using the provided credential to see if they match, but we should not be designing for the simplest case). The CredentialHandler method still allows you to query the credentials, just in a more round about way. So far you have not given a single example where the retrieveCurrentCredential() method would allow access to a user credential, that the CredentialHandler technique would not. Can you give me any scenarios where this approach increases security, as this seems to be the premise that your argument is based on? IMHO the ability to retrieve a credential is a IDM operation, but once you also add credential validation it becomes an authentication manager as well (as I believe Darran has already said). Using the credential to pass state around is also very problematic, as there could be multiple different mechanisms that wish to use the same credential in different ways, which would mean that the credential would need to have mutable fields for all the different state these mechanisms need. I just think this approach will cause problems for the advanced cases, and does not provide any additional security. For digest this is the difference between the digest handler just grabbing the credential it needs and using it directly, vs registering a callback handler, and using the callback handler to expose information about the stored credential using mechanism specific fields in the credential. Also if another mechanism such as SASL is also using the same credentials it gets even more problematic. Do we need two different versions of the same credential stored per user, one for each implementation of CredentialHandler, or are we going to have some way of stacking credential handlers, and we just have to make sure the credential has implementation specific fields for each handler (and just hope that no third party wants to use the same credential classes with different state). I'm sure we could hack around all these problems, and I must admit I have not spent nearly as much time working on this as you guys, but it just seems like this approach will make it more difficult to extend the available authentication mechanisms than it needs to be. Stuart Anil Saldhana wrote: > Shane - you can add the API for this. But I would like to think about it further. I really do not like creds via IM interface. > > On May 1, 2013, at 7:33 PM, Shane Bryzak&lt;sbryzak(a)redhat.com&gt; wrote: > >> Bill, I'm going to concede defeat on this one, so congrats on a >> well-fought victory ;) The one saving grace with the IdentityManager is >> that in an EE environment it is actually wrapped by a >> SecuredIdentityManager, which allows for permission checks to be defined >> for every single IDM operation. With this in mind, it should be trivial >> to implement a permission check for credential retrieval that restricts >> it to only allow the reading of credentials for the currently >> authenticated user (or whatever other permission logic the developer wants). >> >> So, with that in mind I propose the following additional methods for >> IdentityManager: >> >> <T extends CredentialStorage> T retrieveCurrentCredential(Agent >> agent, Class<T> storageClass); >> <T extends CredentialStorage> List<T> retrieveCredentials(Agent >> agent, Class<T> storageClass); >> >> These will essentially delegate to the underlying CredentialStore, and >> if there is none (which will be the case in an LDAP-only configuration) >> you'll get an OperationNotSupportedException. >> >> Will this be sufficient for your requirements? >> >> Shane

Throwing fuel on this, though I ought to know better. I think there is an important distinction here between an identity store which also happens to hold credentials, and an authentication system like PAM or JAAS which has the ability to *verify* credentials. I've seen PicketLink IDM described in this thread in both ways. Do you (the security team) have a clear idea which direction you are trying to move in? If you're working towards a full authentication system, be warned that you're biting off a really major chunk of technology - even PAM (which is arguably one of the most widespread authentication mechanisms around, and is part of the X/Open SSO standard) cannot directly support Kerberos (!) due to API limitations for example. You cannot plausibly pursue this path without understanding just about every authentication scheme in existence, which is clearly not yet the case judging from the content of this thread. There are *hundreds* of schemes that would have to be considered to design a meaningful API that was substantially better than what JAAS already offers. If you're going for a pure identity store, I'd say you're taking on a much more realistic burden, but you must be ready to accept that while authentication systems like JAAS (or PAM) can talk *to* the identity store using custom modules, the identity store could never realistically be used as the frontend to something like PAM or other external authentication systems which do not give full access to credentials. What you'll be making is simply a strongly-typed API to a database, usable only as a backend to actual authentication systems like JAAS and protocols like SASL, FTP, HTTP, SSH, etc. Seems to me like you guys have to accept one or the other path, and stick with it. Don't try to be an identity store that looks and acts somewhat like an authentication system or else you're just going to end up with awkward API constructs and half-baked concepts. Separate your concerns clearly: the IDM is the IDM, the authentication system is the authentication system.

Throwing fuel on this, though I ought to know better. I think there is an important distinction here between an identity store which also happens to hold credentials, and an authentication system like PAM or JAAS which has the ability to *verify* credentials. I've seen PicketLink IDM described in this thread in both ways. Do you (the security team) have a clear idea which direction you are trying to move in? If you're working towards a full authentication system, be warned that you're biting off a really major chunk of technology - even PAM (which is arguably one of the most widespread authentication mechanisms around, and is part of the X/Open SSO standard) cannot directly support Kerberos (!) due to API limitations for example. You cannot plausibly pursue this path without understanding just about every authentication scheme in existence, which is clearly not yet the case judging from the content of this thread. There are *hundreds* of schemes that would have to be considered to design a meaningful API that was substantially better than what JAAS already offers. If you're going for a pure identity store, I'd say you're taking on a much more realistic burden, but you must be ready to accept that while authentication systems like JAAS (or PAM) can talk *to* the identity store using custom modules, the identity store could never realistically be used as the frontend to something like PAM or other external authentication systems which do not give full access to credentials. What you'll be making is simply a strongly-typed API to a database, usable only as a backend to actual authentication systems like JAAS and protocols like SASL, FTP, HTTP, SSH, etc.

Seems to me like you guys have to accept one or the other path, and stick with it. Don't try to be an identity store that looks and acts somewhat like an authentication system or else you're just going to end up with awkward API constructs and half-baked concepts. Separate your concerns clearly: the IDM is the IDM, the authentication system is the authentication system.

Bill, I'm going to concede defeat on this one, so congrats on a well-fought victory ;) The one saving grace with the IdentityManager is that in an EE environment it is actually wrapped by a SecuredIdentityManager, which allows for permission checks to be defined for every single IDM operation. With this in mind, it should be trivial to implement a permission check for credential retrieval that restricts it to only allow the reading of credentials for the currently authenticated user (or whatever other permission logic the developer wants). So, with that in mind I propose the following additional methods for IdentityManager: <T extends CredentialStorage> T retrieveCurrentCredential(Agent agent, Class<T> storageClass); <T extends CredentialStorage> List<T> retrieveCredentials(Agent agent, Class<T> storageClass); These will essentially delegate to the underlying CredentialStore, and if there is none (which will be the case in an LDAP-only configuration) you'll get an OperationNotSupportedException. Will this be sufficient for your requirements? Shane _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Just because a protocol requires access to the raw credential doesn't mean you have to store it in plain text. On 5/5/2013 11:08 AM, Boleslaw Dawidowicz wrote: > If you decide to store passwords in plain text in DB I think you can expect users/customers complaining and I'm sure some projects and deployments will have requirements to not do so. I witnessed both scenarios. Some people have very tough integration challenges and really need to retrieve credentials. For some it is simply no go. In such cases it doesn't matter if it is a real security or just fake perception - my favorite case proving it is password masking. In portal we still keep configuration switch for it. You may need to support both scenarios. > > I lack insight into digest scenario. However to be honest as a user I prefer when systems are not storing my credentials in plain format anywhere. Even if I know that in many cases it doesn't necessarily make them more secure. > > Not saying that we shouldn't do it for this particular case. Still it may hit us back later. > > On May 2, 2013, at 2:33 AM, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: > >> Bill, I'm going to concede defeat on this one, so congrats on a >> well-fought victory ;) The one saving grace with the IdentityManager is >> that in an EE environment it is actually wrapped by a >> SecuredIdentityManager, which allows for permission checks to be defined >> for every single IDM operation. With this in mind, it should be trivial >> to implement a permission check for credential retrieval that restricts >> it to only allow the reading of credentials for the currently >> authenticated user (or whatever other permission logic the developer wants). >> >> So, with that in mind I propose the following additional methods for >> IdentityManager: >> >> <T extends CredentialStorage> T retrieveCurrentCredential(Agent >> agent, Class<T> storageClass); >> <T extends CredentialStorage> List<T> retrieveCredentials(Agent >> agent, Class<T> storageClass); >> >> These will essentially delegate to the underlying CredentialStore, and >> if there is none (which will be the case in an LDAP-only configuration) >> you'll get an OperationNotSupportedException. >> >> Will this be sufficient for your requirements? >> >> Shane >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

How do you think users will want to protect credentials like TOTP secrets? Thats something that will require raw access. On 5/6/2013 9:40 AM, Boleslaw Dawidowicz wrote: > Right. I should have been more clear about this part. Obviously It can still be encoded. Still may not be enough for some more concerned or with specific requirements. Just pointing potential issues. > > On May 6, 2013, at 3:36 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> Just because a protocol requires access to the raw credential doesn't >> mean you have to store it in plain text. >> >> On 5/5/2013 11:08 AM, Boleslaw Dawidowicz wrote: >>> If you decide to store passwords in plain text in DB I think you can expect users/customers complaining and I'm sure some projects and deployments will have requirements to not do so. I witnessed both scenarios. Some people have very tough integration challenges and really need to retrieve credentials. For some it is simply no go. In such cases it doesn't matter if it is a real security or just fake perception - my favorite case proving it is password masking. In portal we still keep configuration switch for it. You may need to support both scenarios. >>> >>> I lack insight into digest scenario. However to be honest as a user I prefer when systems are not storing my credentials in plain format anywhere. Even if I know that in many cases it doesn't necessarily make them more secure. >>> >>> Not saying that we shouldn't do it for this particular case. Still it may hit us back later. >>> >>> On May 2, 2013, at 2:33 AM, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: >>> >>>> Bill, I'm going to concede defeat on this one, so congrats on a >>>> well-fought victory ;) The one saving grace with the IdentityManager is >>>> that in an EE environment it is actually wrapped by a >>>> SecuredIdentityManager, which allows for permission checks to be defined >>>> for every single IDM operation. With this in mind, it should be trivial >>>> to implement a permission check for credential retrieval that restricts >>>> it to only allow the reading of credentials for the currently >>>> authenticated user (or whatever other permission logic the developer wants). >>>> >>>> So, with that in mind I propose the following additional methods for >>>> IdentityManager: >>>> >>>> <T extends CredentialStorage> T retrieveCurrentCredential(Agent >>>> agent, Class<T> storageClass); >>>> <T extends CredentialStorage> List<T> retrieveCredentials(Agent >>>> agent, Class<T> storageClass); >>>> >>>> These will essentially delegate to the underlying CredentialStore, and >>>> if there is none (which will be the case in an LDAP-only configuration) >>>> you'll get an OperationNotSupportedException. >>>> >>>> Will this be sufficient for your requirements? >>>> >>>> Shane >>>> _______________________________________________ >>>> security-dev mailing list >>>> security-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev >>> >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

I'm asking an honest question, how do you think users will want us to protect these credentials? i.e. keystores require a password to access. Should something like this be provided for the identity store? On 5/6/2013 10:29 AM, Boleslaw Dawidowicz wrote: > In some cases there is no other choice. I'm not in disagreement with you here. > > On May 6, 2013, at 4:01 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> How do you think users will want to protect credentials like TOTP secrets? Thats something that will require raw access. >> >> On 5/6/2013 9:40 AM, Boleslaw Dawidowicz wrote: >>> Right. I should have been more clear about this part. Obviously It can still be encoded. Still may not be enough for some more concerned or with specific requirements. Just pointing potential issues. >>> >>> On May 6, 2013, at 3:36 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> Just because a protocol requires access to the raw credential doesn't >>>> mean you have to store it in plain text. >>>> >>>> On 5/5/2013 11:08 AM, Boleslaw Dawidowicz wrote: >>>>> If you decide to store passwords in plain text in DB I think you can expect users/customers complaining and I'm sure some projects and deployments will have requirements to not do so. I witnessed both scenarios. Some people have very tough integration challenges and really need to retrieve credentials. For some it is simply no go. In such cases it doesn't matter if it is a real security or just fake perception - my favorite case proving it is password masking. In portal we still keep configuration switch for it. You may need to support both scenarios. >>>>> >>>>> I lack insight into digest scenario. However to be honest as a user I prefer when systems are not storing my credentials in plain format anywhere. Even if I know that in many cases it doesn't necessarily make them more secure. >>>>> >>>>> Not saying that we shouldn't do it for this particular case. Still it may hit us back later. >>>>> >>>>> On May 2, 2013, at 2:33 AM, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: >>>>> >>>>>> Bill, I'm going to concede defeat on this one, so congrats on a >>>>>> well-fought victory ;) The one saving grace with the IdentityManager is >>>>>> that in an EE environment it is actually wrapped by a >>>>>> SecuredIdentityManager, which allows for permission checks to be defined >>>>>> for every single IDM operation. With this in mind, it should be trivial >>>>>> to implement a permission check for credential retrieval that restricts >>>>>> it to only allow the reading of credentials for the currently >>>>>> authenticated user (or whatever other permission logic the developer wants). >>>>>> >>>>>> So, with that in mind I propose the following additional methods for >>>>>> IdentityManager: >>>>>> >>>>>> <T extends CredentialStorage> T retrieveCurrentCredential(Agent >>>>>> agent, Class<T> storageClass); >>>>>> <T extends CredentialStorage> List<T> retrieveCredentials(Agent >>>>>> agent, Class<T> storageClass); >>>>>> >>>>>> These will essentially delegate to the underlying CredentialStore, and >>>>>> if there is none (which will be the case in an LDAP-only configuration) >>>>>> you'll get an OperationNotSupportedException. >>>>>> >>>>>> Will this be sufficient for your requirements? >>>>>> >>>>>> Shane >>>>>> _______________________________________________ >>>>>> security-dev mailing list >>>>>> security-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/security-dev >>>>> >>>>> _______________________________________________ >>>>> security-dev mailing list >>>>> security-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/security-dev >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> security-dev mailing list >>>> security-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 02/05/13 08:39, Stuart Douglas wrote:

The particular situation I was thinking of was the EL vulnerability we had in Seam a few years ago (which I won't go into detail as this is a public list). Essentially it allowed arbitrary code execution, meaning that the beans of an application could be accessed and invoked directly while bypassing the view layer altogether. I'm not so concerned about malicious code in the application, I believe that's beyond the scope of our responsibility here however I am concerned about developers that may decide to expose the IdentityManager (as a @Named bean or otherwise) without understanding the ramifications of doing so. Basically the intent is to prevent them from shooting themselves in the foot, perhaps I am being overcautious here but the motivation is to limit as much as possible the number of attack vectors for compromising a PicketLink-secured application.

> Sure you can implement it. I think we've proved with JAAS that you can > basically hack whatever you need. But What you're describing Shane is a > hack to get around the inadequacies of the IDM API. How is it a hack to use an SPI for the very purpose that it was designed for?

What our disagreement boils down to is whether or not we should be exposing the raw/secret credential values via the IdentityManager API. We could continue going back and forth with essentially the same arguments but so far neither of us seem to be swayed one way or the other - what I'd like is to hear some opinions from some other people. Should we or should we not be making user credentials queryable?

There's two options here; the first one is to store the private key as an attribute which then makes it a piece of cake to retrieve the value: Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret"); PrivateKey key = attrib.getValue(); The other option is to implement your own CredentialHandler as mentioned previously. The design decision to insulate the actual credential values from the API was intentional, and at the moment the only time they are exposed to the API is when they are created for the very first time. With there seemingly being a major password hack on the news every week it is in our best interest to reduce the number of attack vectors that make this kind of thing possible, hence the decoupled design. Also, I don't consider writing your own CredentialHandler implementation a hack, in fact we have a quickstart for it as it is something we expect many of our developers to have to do themselves. On 01/05/13 06:20, Bill Burke wrote: > So you're saying that instead of doing straightforward code to get at > information stored within the IDM to perform a hash a full request or > response, he has to hack a handler to do it through a verify() call? > > Would it be the same if I wanted to sign/encrypt an arbitrary set of > bytes with a private key/secret stored in the IDM? I'd have to hack a > verifier to tunnel this? > > I thought we were rewriting these security APIs so that we didn't have > to do stupid pet tricks anymore? > > On 4/30/2013 4:12 PM, Shane Bryzak wrote: >> Yes, you can absolutely do this. >> >> >> On 30/04/13 23:56, Darran Lofthouse wrote: >>> Alternatively - could I plug-in my own Credential types and a >>> corresponding CredentialHandler for them? >>> >>> On 30/04/13 14:47, Darran Lofthouse wrote: >>>> Sent my last message using the wrong account so it may arrive but >>>> writing again just in case. >>>> >>>> The Digest Credential is what we need stored but we would potentially >>>> need more than one to be stored to cope with different hash algorithms >>>> being used. >>>> >>>> The issue regarding what is currently in PicketLink is that it is >>>> causing HTTP specific aspects of Digest authentication to leak into the >>>> IDM and at the same time is only implementing a small subset of the >>>> RFC2617 specification. We need access to the same pre-prepared digests >>>> for SASL authentication but this is using a slightly different format >>>> for the digests that are compared. >>>> >>>> In addition to this we need the entire messages being exchanged both >>>> inbound and outbound to be digested along with these pre-prepared hashes >>>> for the purpose of adding integrity protection for the messages >>>> exchanged. There is also a middle ground of providing an appropriate >>>> header so that the server can also prove it knows the clients password. >>>> >>>> This is why we need access to the pre-prepared digest for the chosen >>>> algorithm or at the very least an option to request PLIDM pushed it into >>>> a MessageDigest instance (Maybe PLIDM provides the MessageDigest and >>>> wraps it). >>>> >>>> Otherwise there is going to be a lot of HTTP specific and SASL specific >>>> code to potentially push into an IDM and the IDM is going to have to be >>>> much more involved in the actual message exchanges. >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> On 30/04/13 13:58, Shane Bryzak wrote: >>>>> What PicketLink stores for digests is the latter [1] (in no situation do >>>>> we ever store plain text passwords). There are essentially two methods >>>>> for validating and managing credentials in the IdentityManager [2] >>>>> (three if you count one extra overloaded method): >>>>> >>>>> void validateCredentials(Credentials credentials); >>>>> void updateCredential(Agent agent, Object credential); >>>>> >>>>> There is no API method for retrieving an actual credential value so by >>>>> design credential storage is quite secure. >>>>> >>>>> To briefly summarise how things work for a digest authentication in >>>>> PicketLink; we would pass in an instance of DigestCredentials [3] to the >>>>> IdentityManager.validateCredentials() method, which is essentially a >>>>> wrapper around a Digest [4] (which should look quite familiar). The >>>>> actual implementation of the validation logic can be found in >>>>> DigestCredentialHandler [5]. >>>>> >>>>> >>>>> [1] >>>>> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >>>>> [2] >>>>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>>>> [3] >>>>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>>>> [4] >>>>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>>>> [5] >>>>> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >>>>> >>>>> Shane >>>>> >>>>> On 30/04/13 22:26, Darran Lofthouse wrote: >>>>>> As there is going to be an integration layer between Undertow and >>>>>> PicketLink IDM I think the main requirement for PicketLink IDM is going >>>>>> to be: - >>>>>> >>>>>> - Where PLIDM has access to plain text passwords for a specified >>>>>> account and using the specified digest algorithm generate the digest for >>>>>> the username, realm and password separated by colons. >>>>>> >>>>>> - Where PLIDM is storing pre-prepared digests for a specified account >>>>>> look up the pre-prepared username, realm, password digest for the >>>>>> algorithm specified. >>>>>> >>>>>> This latter option relates to something I brought up a while ago where a >>>>>> single credential could be associated with an account in a number of >>>>>> different formats - what this means is that the Digest algorithms can >>>>>> potentially go beyond MD5 to use stronger digest algorithms. >>>>>> >>>>>> The pre-prepared digests do offer some protection but PLIDM would still >>>>>> be responsible for storing them securely to provide protection against >>>>>> accidental disclosure. The most important thing however is that we do >>>>>> not need the plain text passwords to be passed onto the Undertow or SASL >>>>>> classes handling the actual authentication. >>>>>> >>>>>> Regards, >>>>>> Darran Lofthouse. >>>>>> >>>>>> >>>>>> On 30/04/13 12:56, Shane Bryzak wrote: >>>>>>> Looks pretty straight forward - what do you need from the PicketLink >>>>>>> side for this? The PLIDM implementation should be quite simple, I can >>>>>>> help out with it if required. >>>>>>> >>>>>>> Shane >>>>>>> >>>>>>> On 30/04/13 19:24, Darran Lofthouse wrote: >>>>>>>> I have been saying for a while that I need to raise a discussion >>>>>>>> regarding the verification of Digest based requests against an >>>>>>>> IdentityManager. >>>>>>>> >>>>>>>> At the moment this is predominantly needed for Undertow although there >>>>>>>> is also a need for same with SASL. >>>>>>>> >>>>>>>> The following document describes the proposed use of the Undertow >>>>>>>> IdentityManager API and the requirement for the implementation i.e. what >>>>>>>> we would need from PicketLink IDM once wrapped in the WildFly integration: - >>>>>>>> >>>>>>>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... >>>>>>>> >>>>>>>> The three methods on the IdentityManager interface previously used for >>>>>>>> Digest based authentication will all be removed. >>>>>>>> >>>>>>>> An identity manager that can provide this capability will also be >>>>>>>> compatible with SASL based authentication without needing to be aware of >>>>>>>> the actual verification requirements within SASL. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Darran Lofthouse. >>>>>>>> _______________________________________________ >>>>> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 01/05/13 17:03, Darran Lofthouse wrote: > The problem I see with this is that the CredentialHandler that gets > implemented has to take on the task of leaking the Credential, in this > case I think we should verify on the response message as that is > generated after the call to verify. > > Ideally the Credential I pass into the IDM needs to look similar to the > one I provided on the initial Undertow article - to be able to generate > a header to verify the integrity of the message (or even to properly > implement {SLG}-sess) I need the appropriate hashed value. > > Alternatively I may have one additional option for me but I don't think > it covers Bill's scenario (Also I think other projects may be missing > from the discussion such as JBossWS although they probably would require > the same as Bill). > > One thing I may be able to do in a CredentialHandler is create the > appropriate MessageDigest instance and push the pre-prepared digest > straight into it - this MessageDigest could then be passed to the > Credential being verified - the calling code could then have access to > the MessageDigest. That way the calling code would have what it needs > without actually being exposed to the stored Credential. This is definitely how I would recommend implementing this scenario. The Credentials object that is passed into CredentialHandler.validate() is a great place to pass state back and forth between the CredentialHandler and the caller. > > This way the HTTP specific portion of verification can still live > outside the IDM which I believe is still the correct location for it. > > Regards, > Darran Lofthouse. > > > On 30/04/13 21:54, Shane Bryzak wrote: >> There's two options here; the first one is to store the private key as >> an attribute which then makes it a piece of cake to retrieve the value: >> >> Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret"); >> PrivateKey key = attrib.getValue(); >> >> The other option is to implement your own CredentialHandler as mentioned >> previously. The design decision to insulate the actual credential >> values from the API was intentional, and at the moment the only time >> they are exposed to the API is when they are created for the very first >> time. With there seemingly being a major password hack on the news >> every week it is in our best interest to reduce the number of attack >> vectors that make this kind of thing possible, hence the decoupled >> design. Also, I don't consider writing your own CredentialHandler >> implementation a hack, in fact we have a quickstart for it as it is >> something we expect many of our developers to have to do themselves. >> >> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

You'd just write additional handlers and storage classes for your specific protocols (i.e. SASL). These objects can be provided to Picketlink IDM *at runtime* correct? So doesn't look like there is any leakage as your Undertow protocol handler would be providing the callback objects.

> In addition to this we need the entire messages being exchanged both > inbound and outbound to be digested along with these pre-prepared hashes > for the purpose of adding integrity protection for the messages > exchanged. There is also a middle ground of providing an appropriate > header so that the server can also prove it knows the clients password. Couldn't you store the Http Request, byte[] of full message inside the Credentials parameter passed into the Handler's verify method? You have to cache the message anyways so that the application can obtain what it needs.

> This is why we need access to the pre-prepared digest for the chosen > algorithm or at the very least an option to request PLIDM pushed it into > a MessageDigest instance (Maybe PLIDM provides the MessageDigest and > wraps it). > Otherwise there is going to be a lot of HTTP specific and SASL specific > code to potentially push into an IDM and the IDM is going to have to be > much more involved in the actual message exchanges. Again, I don't think this is true because the Undertow Digiest Authenticator can produce the appropriate handlers, no?

Maybe Shane should review why they have what they have? In a previous email thread he talked a bit about chained IDMs where one or all may have to verify a credential. Also, maybe an option to query storage directly should be available from Picketlink IDM API (if there isn't one already). The keeps both metadata and verification separate concerns, IMO.

Darran, if there is anything you find missing in PL IDM from UT perspective, please mention it here. The earlier the better considering PL3 is scheduled for June. :) Regards, Anil On 04/30/2013 09:48 AM, Darran Lofthouse wrote: > On 30/04/13 15:05, Bill Burke wrote: >> You'd just write additional handlers and storage classes for your >> specific protocols (i.e. SASL). These objects can be provided to >> Picketlink IDM *at runtime* correct? So doesn't look like there is any >> leakage as your Undertow protocol handler would be providing the >> callback objects. > Really in this case it is not really a simple relationship of one > credential type to one protocol handler. > > We may be able to get multiple representation of the same credential > into one Credential class e.g. we could have one NewDigestCredential > that can store the MD5 version in addition to a SHA-256 version. > > However this NewDigestCredential would need to be used by both a > HTTPDigestCredentialHandler and a SASLDigestCredentialHandler. > > Should add this does not cover another option we have with Digest > authentication where the first round trip between the client and server > established effectively a shared key based off the stored credential - > for all future interactions with the client authentication is based on > this shared key as long as it is valid and not the stored credentials. > >>> In addition to this we need the entire messages being exchanged both >>> inbound and outbound to be digested along with these pre-prepared hashes >>> for the purpose of adding integrity protection for the messages >>> exchanged. There is also a middle ground of providing an appropriate >>> header so that the server can also prove it knows the clients password. >> Couldn't you store the Http Request, byte[] of full message inside the >> Credentials parameter passed into the Handler's verify method? You have >> to cache the message anyways so that the application can obtain what it >> needs. > That may be an option for the inbound message, we need to read the > message from the client to be able to create it's digest and still have > the message available for the final HttpHandler to be able to read it. > > However this does not cover the outbound response message where the > whole response also needs to be digested. > >>> This is why we need access to the pre-prepared digest for the chosen >>> algorithm or at the very least an option to request PLIDM pushed it into >>> a MessageDigest instance (Maybe PLIDM provides the MessageDigest and >>> wraps it). >>> >>> Otherwise there is going to be a lot of HTTP specific and SASL specific >>> code to potentially push into an IDM and the IDM is going to have to be >>> much more involved in the actual message exchanges. >>> >> Again, I don't think this is true because the Undertow Digiest >> Authenticator can produce the appropriate handlers, no? > Remember this is not just Undertow - this is Undertow and SASL - both of > which need verification and header generation based on the same stored > credentials. > >> Maybe Shane >> should review why they have what they have? In a previous email thread >> he talked a bit about chained IDMs where one or all may have to verify a >> credential. Also, maybe an option to query storage directly should be >> available from Picketlink IDM API (if there isn't one already). The >> keeps both metadata and verification separate concerns, IMO. > As I mentioned on my other reply, a secure mechanism to have the stored > credential pushed into a MessageDigest may also be suitable. > > Another alternative I could just implement an > UndertowDigestCredentialHandler that handles the DigestCredential from > my original article and calls the verifyHA1() this would give me the > hash I require for the subsequent operations and validation of the message. > >> >> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

I have been saying for a while that I need to raise a discussion regarding the verification of Digest based requests against an IdentityManager. At the moment this is predominantly needed for Undertow although there is also a need for same with SASL. The following document describes the proposed use of the Undertow IdentityManager API and the requirement for the implementation i.e. what we would need from PicketLink IDM once wrapped in the WildFly integration: - https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentic... The three methods on the IdentityManager interface previously used for Digest based authentication will all be removed. An identity manager that can provide this capability will also be compatible with SASL based authentication without needing to be aware of the actual verification requirements within SASL. Regards, Darran Lofthouse. _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev