A small tool to view real-world ActivityPub objects as JSON! Enter a URL
or username from Mastodon or a similar service below, and we'll send a
request with
the right
Accept
header
to the server to view the underlying object.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"ostatus": "http://ostatus.org#",
"atomUri": "ostatus:atomUri",
"inReplyToAtomUri": "ostatus:inReplyToAtomUri",
"conversation": "ostatus:conversation",
"sensitive": "as:sensitive",
"toot": "http://joinmastodon.org/ns#",
"votersCount": "toot:votersCount",
"litepub": "http://litepub.social/ns#",
"directMessage": "litepub:directMessage",
"Hashtag": "as:Hashtag"
}
],
"id": "https://infosec.exchange/users/breditor/statuses/109935281486180225",
"type": "Note",
"summary": null,
"inReplyTo": null,
"published": "2023-02-27T06:27:50Z",
"url": "https://infosec.exchange/@breditor/109935281486180225",
"attributedTo": "https://infosec.exchange/users/breditor",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://infosec.exchange/users/breditor/followers"
],
"sensitive": false,
"atomUri": "https://infosec.exchange/users/breditor/statuses/109935281486180225",
"inReplyToAtomUri": null,
"conversation": "tag:infosec.exchange,2023-02-27:objectId=47608229:objectType=Conversation",
"content": "<p>This week I’m arguing that the catch-all rule for an <a href=\"https://infosec.exchange/tags/Okta\" class=\"mention hashtag\" rel=\"tag\">#<span>Okta</span></a> sign-on policy should be “deny everything.” </p><p>Okta’s policy rules work like this: The first rule Okta evaluates during a request sits at the top of the rule stack. If the rule doesn’t match, it evaluates the rule beneath it. On it goes until a rule matches. </p><p>When you first set up an org, the pragmatic default is to allow access after primary authentication. </p><p>My argument is that once you’ve configured and tested your sign on policies, your catch-all should be set to deny. I think of this as an additional safety net (in addition to thorough testing) for when you modify policies/rules. Adversaries are often better at testing for unexpected access scenarios than admins. </p><p>My blog post offers a few workflow suggestions for identifying requests that fall through the cracks using catch-all and “canary” rules. <br /><a href=\"https://sec.okta.com/catchallsandcanaryrules\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">sec.okta.com/catchallsandcanar</span><span class=\"invisible\">yrules</span></a></p>",
"contentMap": {
"en": "<p>This week I’m arguing that the catch-all rule for an <a href=\"https://infosec.exchange/tags/Okta\" class=\"mention hashtag\" rel=\"tag\">#<span>Okta</span></a> sign-on policy should be “deny everything.” </p><p>Okta’s policy rules work like this: The first rule Okta evaluates during a request sits at the top of the rule stack. If the rule doesn’t match, it evaluates the rule beneath it. On it goes until a rule matches. </p><p>When you first set up an org, the pragmatic default is to allow access after primary authentication. </p><p>My argument is that once you’ve configured and tested your sign on policies, your catch-all should be set to deny. I think of this as an additional safety net (in addition to thorough testing) for when you modify policies/rules. Adversaries are often better at testing for unexpected access scenarios than admins. </p><p>My blog post offers a few workflow suggestions for identifying requests that fall through the cracks using catch-all and “canary” rules. <br /><a href=\"https://sec.okta.com/catchallsandcanaryrules\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">sec.okta.com/catchallsandcanar</span><span class=\"invisible\">yrules</span></a></p>"
},
"attachment": [],
"tag": [
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/okta",
"name": "#okta"
}
],
"replies": {
"id": "https://infosec.exchange/users/breditor/statuses/109935281486180225/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://infosec.exchange/users/breditor/statuses/109935281486180225/replies?only_other_accounts=true&page=true",
"partOf": "https://infosec.exchange/users/breditor/statuses/109935281486180225/replies",
"items": []
}
},
"likes": {
"id": "https://infosec.exchange/users/breditor/statuses/109935281486180225/likes",
"type": "Collection",
"totalItems": 4
},
"shares": {
"id": "https://infosec.exchange/users/breditor/statuses/109935281486180225/shares",
"type": "Collection",
"totalItems": 1
}
}