Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Description

Reviewing possible sources of OATH and probably other OTP solutions suggests to me that it would be good to have more generic support for encrypted attributes in the resolver that isn't tied to any specific attribute-consuming code and is just handled automatically.

Not sure of the right layering, but a DecryptedAttributeDefinition seems plausible as a way to lever it in.

Environment

None

Attachments

3
  • 15 Jan 2020, 01:19 PM
  • 15 Jan 2020, 12:57 PM
  • 15 Jan 2020, 12:57 PM

Activity

Show:

Scott Cantor July 21, 2020 at 4:12 PM

Tested sealer command line in a proper install, worked fine. Since we're looking at moving the system beans into the jars I don't think it's worth looking at altering the default layout right now.

Scott Cantor July 1, 2020 at 5:34 PM

Added CLI wrapper allowing a DataSealer bean in a Spring file to be used to encrypt or decrypt strings. Needs testing "in place" in an IdP install.

Scott Cantor June 30, 2020 at 5:46 PM

I guess it occurs to me this might be of utility in encrypting the client secrets for the OIDC metadata work.

The resolution side is trivial, see https://wiki.shibboleth.net/confluence/display/IDP4/DecryptedAttributeDefinition for how to wire it up.

Scott Cantor June 30, 2020 at 5:43 PM

A modified version of the patch is comitted and docs added.

The DataSealer was fixed to allow wrapping of unexpiring data. The encoding is done by embedding a zero as the expiration, but that's not exposed to callers.

TODO: Some kind of assistance using the DataSealer to encrypt. A CLI tool could be built with hardwired assumptions about the keys, but using a REST API to the IdP would allow instant use of any other implementations of the various interfaces, so remote key sources would be usable. This could be done as a Spring Boot app too I suppose, maybe that's worth exploring.

Joseph Fischetti January 15, 2020 at 1:11 PM
Edited

I'm sorry, I hadn't 'git add'ed the new files.  
I resubmitted the patch with a license file.  The new patch does include the following:

create mode 100644 idp-attribute-resolver-impl/src/main/java/net/shibboleth/idp/attribute/resolver/ad/impl/DecryptedAttributeDefinition.java create mode 100644 idp-attribute-resolver-impl/src/test/java/net/shibboleth/idp/attribute/resolver/ad/impl/DecryptedAttributeTest.java create mode 100644 idp-attribute-resolver-spring/src/main/java/net/shibboleth/idp/attribute/resolver/spring/ad/impl/DecryptedAttributeDefinitionParser.java

 

There are the following notes:

  1. "DecryptedAttributeTest.java" was copied from SimpleAttributeTest and is almost entirely commented out.  I didn't include tests for that module, since I was working more on testing via idp-attribute-resolver-spring.  I do plan to actually make it function.

  2. attribute-resolver.xml in idp-attribute-resolver-spring/src/test/.../spring/ includes a reference to a locally hosted schema file at the top.  I wasn't sure how to get it to reference the schema changes made in idp-schema/src...shibboleth-attribute-resolver.xsd, which include the new "Decrypted" complexType name. 

  3. The patch file submitted includes patches for some of the commits (0001-Branched..., 0002-Added..., 0003-Updates..., etc).  Those patch files themselves can effectively be removed.  They were erroneously created when I did 'format-patch' and then added when I added the new class files.  I can rebuild the patch (again) if it's a problem. I resubmitted a new patch file (DecryptedAttribute-nopatches.patch) that doesn't include these patch files.  

Something went wrong on our end

If this keeps happening, share this information with your admin, who should contact support.

Hash D3XM4T Trace d270c74c84e842e0a9468554f849e816
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Scott Cantor

Reporter

Scott Cantor

Components

Fix versions

Flag notifications